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A New 32-Bit VLSI Computer Family 
Part II— Software 

Based on HP's proprietary 32'bit VLSI NMOS-ill technology, 
the HP 9000 Series 500 Computers use local area 
networking and HP-UX, HP's enhanced version of UNIX''' 
An advanced version of BASIC that uses run-time compiling 
is available on the Model 520 integrated workstation. 

by Michael V. Hetrick and Michael L. Kolasar 



IN 1981 HEWLETT-PACKARD described the develop- 
ment of a single-chip 32-bit processor^ fabricated with 
a new VLSI process technology called NMOS UI.^ This 
new teclmology was also used to develop four other 32-bit 
chips that, coupled with Ihe design of a special copper- 
cored circuit board called a finstrate^ enable a powerful 
multiprocessor 32-bit computer system to be packaged 
within a module no larger than a loaf of bread. The design 
of the five chips, the module, and the finstrate, and the 
NMOS-III process were discussed in last August's issue. 

The compact module » called the Memory/Processor Mod- 
ule, forms the heart of a desktop engineering computer 
workstation, the HP 9000 Computer, Introduced by HP in 
1983. Now known as the HP 9000 Model 520, it contains 
a 5V4-inch flexible disc drive, has four 110 slots, and has a 
choice of either a color or monochromatic 13-inch CRT 
display- Depending on the choice of the twelve finstrates 
possible in the Memory /Processor Module, up to three 
CPlJSf ihree I/O processors, or 2.5M bytes of RAM can be 
installed. Available options include an internal thermal 
printer and an internal lOM-hyte hard disc memory. 

A .sophisticated interna i operating system, called SUN. 
was developed to coordinate this compact multiprocessor 



computer system. A high-performance interactive high- 
level language system is required to allow a user to take 
full advantage of the features included in the Model 520, 
Au enhanced version of BASIC and a run-time com pi 1 log 
technique were developed. This version was designed as 
a superset of the BASIC used on earlier HP desktop comput- 
ers so that users could easily port existing software to the 
Model 520. 

In late 1983, the HP 9000 family of computers was de- 
fined to include some earlier 16-bit technical desktop com- 
puters,^ now known as the Series 200, and alternative pack- 
ages for the Memory/Processor Module, which with the 
Model 520, form the Series 500. To simplify the porting of 
software developed by other companies to the IW 9000 
family, HP-UX, an enhanced version of UNIX™, was de- 
veloped. LAN 9000 was developed to provide local area 
networking. 

Fig. 1 depicts all current HP 9000 models. The primary 
distinction between the Series 200 and Series 500 Comput- 
ers is in their microprocessor, or central processing unit 
(CPU), and the ensuing system design. Ail Series 200 mod- 
els are based on Motorola's 16/3 2- bit 68000 microprocessor, 
while all Series 500 models use HP's proprietary 32 -bit 

UNIX Is a U.S tfacfemarH of Boll Laborsiories.. 
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Fig. 1. The HP 9000 family of 
computers indudes the Series 
200 and the SerieB 500 Comput- 
ers. The Senes 200 ts based on 
th& 16132-bit 68000 micropro- 
cessor ar\d the Series 500 is 
based on HP's proprietary 32-bit 
VLSI NMOS-llt chip set. The Series 
200 is tower m cost ar^d the Series 
500 has higher performar)ce Pro- 
grams deveioped in BASIC on the 
Series 200 can be ported to the 
f^odel 520 of the Series 500 for 
decreased computatton time and 
other performance advantages. 
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Contrasting Project Management 

The relative magnitudes of the BASIC and HP-UX projects 

created interesting and contrasting software management tech- 
niques, BASIC, being relatively small in code size by today's 
standards (less than one megabyte) v^as implemented enlirely 
wfthin HPs Fort Collins Systems Division (FSD). A developmeni 
environment known as MODCAL, whfch ran on previous-gener- 
ation desktop computers, was an effective tool fof code develop- 
ment. Since the project was oKecuted by a few engineering 
groups in one department, coordination among the design team 
was extremely efficient. 

HP-UX devetopment. on the other hand, was much larger in 
scope; it resulted in approximately 1 megabytes of system code. 
Features such as muftiple languages, graphics, networking, and 
fundamentai program development toois were required. HP en- 
tities outside of FSD had the expertise to contribute in some of 
these key areas. Thus, two California organizations— the Com- 
puter Language Laboratory (CLL) and the Engineehng Produc- 
tivity Division (EPD) — along with the Colorado Networks Opera- 
tion (CNO) provided FSD with major software subsystems. CLL 
produced the FORTRAN and Pascal compilers. EPD developed 
HP's weH-known two- and three-dimensional graphics libraries, 
and CNO provided most of the data communications and net- 
working software. 

FSD ported the UNIX'** commands and created the System III 
UNIX interface to the existing Series 500 operating system. FSD 
was aiso responsible for coordinating the entire software develop- 
ment and integrating all subsystems into a cohesive product. 

As the HP-UX asynchronous communications software be- 
came functional, it was used to transmit messages and internal 
software updates between divisions. FSD and CNO capitalized 
on high-speed locai area network prototype hardware and soft- 
ware to update tocal systems electronically. 

Thus, many HP-UX software subsystems became key develop- 
ment tools even as they were being created. (The UNIX command 
set. C, FORTRAN, and Pascal compilers, and SCCS, the source 
code control system, are additional examples.) Their everyday 
use not onfy contributed to our development productivity, but 
also served as a prime example of how intemaJ use of what will 
become a product impfo\/es the product's overall quality in a 
way that is not otherwise possible. 

*UNIX is a U.S. trademark ot Bell Latyoratofies 

-Mfchae! V. Hetrick 
Michaei L Kotesar 



CPU chip set mentioned earlier. Highly compatible system 
software spans the lower-cost Series 200 and higher-perfor- 
mance Series 500 workstations to provide a broad price/per- 
formance product family. BASIC is offered on all but the 
Model 530 and Model 540; HP-UX is offered on all but the 
Model 216 and Model 226. A standard HP Pascal develop- 
ment environment also appears on all Series 200 models. 
This issue discusses the development of the Series 500 
software systems with the exception of the multitasking, 
graphics, and I/O subsystems for Model 520 BASIC. They 
will be discussed with the hardware design of the Series 
500 in the May issue, which will conclude the story of the 
development of the HP 9000 Series 500 Computers. 

Software Organization 

The software for the Series 500 is modular and is easily 
decomposed into smaller building blocks. The design kept 



the internal SUN operating system clearly distinct from 
the code for the BASIC language. This separation was 
necessary to provide the foundation for a true multilingual 
system. For example, we knew that the Series 500 with 
virtual memory would be an excellent FORTRAN engine. 

The separation or layering of the software made it neces- 
sary to define a powerful and flexible set of operating sys- 
tem entry points to support the real -time event-driven 
BASIC language needs. This set of underpinnings also 
serves as the basis for the HP-UX system. 

The SUN operating system hides most of the hardware 
details from the higher-level subsystems. The initial ver- 
.sion of SUN supports the Model 520's demanding 700- 
key vvord BASIC language with its new run -time compiler. 
The support for multiple CPUs and I/O processors was 
designed in from the beginning. The BASIC language sys- 
tem supports memory-resident programs and data, but does 
not support virtual memory. Besides the BASIC language 
mainframe code, several option packages extend its capa- 
bilities by adding two- and three-dimensional color 
graphics, HP's IMAGE data base management and query 
.system, extended 1/0, extended mass storage with multiple 
disc formats, multitaskingj advanced programming such as 
matrix manipulations, and I/O drivers for a variety of inter- 
faces and devices. BASIC'S highly integrated human inter- 
face causes it to be provided only on the Model 520. the 
integrated desktop version of the Series 500, Special 
hardware in the Model 520's display unit is used to achieve 
excellent performance for BASIC'S text and graphics win- 
dow facilities. The Model 520 keyboard contains special 
control keys used in BASIC, such as RUN, STOPp STEP, and 
PAUSE, in addition to the keys normally found on a terminal 
keyboard. 

We chose UNIX as the best available environment to 
support FORTRAN and other standard languages. A second 
version of the SUN operating system was built using the 
modules from the first version, but with the important virtual 
memory feature added. The diagrams in Fig. 2 and Fig. 3 
show the similarity of the BASIC and HP-UX systems. This 
leverage paid off handsomely, because almost from the 
beginning, the terminals, discs and printers worked reliably 
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Fig. 2. Block diagram of the BASiC language system for the 
HP 9000 Moaei 520 Computer. 
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for HP-UX. Also, the real*time and mulllprocessor design 
carried over to HP-UX to give it a more solid basis for 
performance extensions, device I/O. and real* time than 
could be achieved with a ported system. 

A thin layer of code maps the HP-UX intriosrc calls into 
the underlying SUN intfinsics. The same HP Structured 
Directory Formal (SDF) hierarchical file system used by 
BASIC is also used by HP-UX, It is almost indistinguishable 
from the System HI UNIX file system except that it is more 
reliable and less susceptible to corruption from power fail- 
ures and system crashes. This layered design was a concern 
because it could lead to deviations from the UNIX seman- 
tics defined by Bell Laboratories. Therefore* a set of exten- 
sive and comprehensive kernel test programs was devised to 
determine if any detectable differences had been introduced. 
With only a small additional effort, the layered kernel 
passed the validation tests. The same set of test programs 
is being used to verify the Series 200 HP-UX kernel and 
future releases of the Series 500 kernel. 

The commands and libraries offered are selected from 
both the Bell Laboratories and the University of California 
at Berkeley versions of UNIX. Those most needed for pro- 
gram transport and development are included. The three 
user program languages offered are C, Pascal, and FORTRAN 
77. The calling sequences allow mixing of languages at the 
subroutine level and the sharing of all library routines. 

The definition of HP-UX includes not just compatibility 
with Bell Laboratories' UNIX System 111, but also HP exten- 
sions. The current system offers IMAGE data base manage- 
ment, AGP/DGL graphics, and local area networking based 
on ARPANET TCP/IP and Ethernet protocols with both file 
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Rg, S, Block diagram of the HP-UX oper^ng system for the 
HP QOOO SBfies 500 Computers. 

and process services. 
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The Development of a BASIC Language Subsystem 



Ttie development of the BASJC language subsystem for the 
HP 9000 Model 520 Computer had one primary goal— lo allow 
this new workstation to be a complete functional replacement 
for the HP 9835 and HP 9845 Computers^ whiie achjeving at 
least tan times the performance of the HP 9845 by ushg HP's 
new 32-bit NMOS- 1 11 custom VLSI chip set,^ In addition, new 
features were needed to keep pace with the new applications 
that such a capable machine would encompass The develop- 
ment schedule for this top-of-the-line BASIC machine ran in paral- 
lel with the chip set development. 

The design team decomposed these high-tevel goals into many 
challenging technical goals, uppermost being to provide a 
growth path for HP's current BASIC language customers through 
a high degree of compatibility, and to add new functions suited 
to the power of the new hardware. The BASIC language was 
unified and extended in cooperation wrlh the Series 200 Compul- 
ers^ language team while reta»ning a high degree of program 
compatibiliiy with ihe earlier HP 9335 and HP 9845. Thus, pro- 
grams from eilher generation of machines move easily onto the 
Model 520. Almost no differences are notable between Series 
200 BASIC and Model 520 BASIC. Even though most HP 9845 
statements are retajned, the uniformity of the evolving language 
dictated that some differences would result. An optional translator 
for HP 9845 programs to achieve a more precise semantic match 
is available. 

The major technical conlnbuiion to support the performance 
goals was a run-time compiler for the BASIC language. This 
compiler appears to the programmer to be the same as our 



tradilionat interpretive environment, preserving such features as 
tracing, line stepping, execution of statements from the Keyboard 
and manipulation of a running program's variables. A running 
program can be paused, tines can be added, deleted, or mod- 
ified, and execution then continued from its point of suspension. 
All of these features are still supported even though the user's 
program is not interpreted, but compiled into object code and 
directly executed 

The resulting high-productivity programming environment uses 
execution modes and trap instructions built into the new proces- 
sor. Parallel chip set and software development allowed many 
specialized instructions to be added to the processof in support 
of these interactive features as well as the language itself. These 
included some of the traps, the string manipulation set. and bit 
manipulation. The resulting BASIC language system has over 
700 keywords that encompass significant data base manage- 
ment, graphics and I/O capabilities 

The new compiled environment retains the event-driven, real- 
time program control of the HP 9845 and HP 900O Model 226 
Computers. Program branching and flow are tied to both 
hardware and software events through the use of ON statements. 
These statements define the asynchronous branching that is to 
occur when selected events happens. 

Also in support of the performance objectives, the new machine 
uses the emerging IEEE binary floating-point mathematics stan- 
dard instead of the traditional decimal mathematics, In addilicn 
to mai<ing use of the fast microcoded floating-point on the micro- 
processor, binary mathematics is used fn new algorithms for 



MARCH I9a4 HEWLETT-PAGKARO JOURI^AL 5 



)Copr. 1949-1998 Hewlett-Packard Co. 



computing transcendental and other functions whfch are both 
faster and more accurate. 

Multttasking was added to improve the user's access to the 
machine and to use the improved processor power. Simultaneous 
program execution and development are now supported. Up to 
60 user processes can be run simultaneousJy These processes 
share the system resources and peripherals. For Gommunciatlons 
and synchronization they have "named -event" signaling. Memory 
resident volumes and Files were added for rapid shared-data 
access. File locking allows for atomic (indivisible) update of a 
shared file. 

The system architecture provides for multiple identical CPUs. 
This feature was incorporated into the operating system so that 
the power of many processors could be directed at runable 
tasks. The fundamental design supports these multiple CPUs as 
homogeneous and anonymous computing resources. Since all 
CPUs have symmetric access to all 1/0. there is no need to 
Introduce master-slave relationships, The only externally visible 
effect of adding more CPUs is increased throughput. 

Full-screen editing and multiple user-defined windows in both 
graphics and alpha displays were added to improve the human 
interface. Boih public and private windows are supported, includ- 
ing arbitrary window overlap and lasi update priority display. 
These windows act much like sheets of paper on your desk, with 
the topmost sheets occluding the sheets below where they over- 
lap. The window structure rs dynamic — even the system message 
areas can be relocated anywhere on the screen. 

An example of new hardware capability that mapped into a 
new set of language features is the inlemal, nonvolatile^ reat-lime 
clock, which fadlitates using time to schedule program events. 
The new file system also uses the clock to time-stamp tiles as 
they are created or changed and the lister dates hard copy. 

The graphics definition was extended to support multiple input 
devices with tracking and event capture, and the transformation 
pipeline includes both two- and three-dimensionaE modeling 
modes 

Development Tools 

A very accurate emulation program that mimicked the execu- 
tion of the new machine's instruction set was written for execution 

on the distributed HP 9845 workstations. This software emulation 
was so accurate that it took only ten minutes from the time the 
first chip set was delivered to the software team until the system 
was up and running a BASIC program in compiled code on the 
new Model 520 hardware. 

The instruction set^ of the new VLSI CPU chip provided the 
hooks for a highly interactive symbolic debugging tool. This de- 
bugger provided a simple transition between running and step- 
ping of systems programs. Procedure, line, and assembly level 
stepping are selected on the fly. Program fbw is displayed sym- 
bolically at the appropriate level. Variables can be referenced 
symbolically. 



Pascal was chosen as the systems programming language 
with extensions for separate modular compilation to support large 
team program development. This new language is called fvlOD- 
CAL for MODular PasCAL- MODCAL is very similar to Wirth's 
Moduia II. but was designed independently by HP. For the pro- 
gramming environment, the UCSD (University of California at San 
Diego) p system was selected because it was written in Pascal, 
was easily ported to the HP 9845. and had the other tooEs, such 
as editors, that were needed 

Another important decision was to separate the BASIC lan- 
guage from its operating system support. Clear separation of 
the operating system provided code that could be leveraged for 
the HP-UX project and reduced the cost of maintaining the Model 
520 BASIC sysiem. The underpinnings for the HP 9000 multiple- 
CPU HP-UX system are the same operating system modules 
used for BASIC. 

Over 750K bytes of code are in the BASIC system for the 
Model 520, forming the most powerful program development 
environment ever provided for an HP desktop computer system. 
The resulting system's speed, graphics, and real-time, event- 
driven 1/0 capability make il a very powerful engineering too). A 
large number of HP 9845 and Model 226 programs have been 
easily moved onto the Model 520. Performance gains average 
BO to 1 00 times the performance of the HP 9845 B Computer and 
more than 10 times the performance of the HP 9845, option 200. 
for computation-limited tasks. The same computational tasks av- 
erage 15 times faster than on the BASIC version of the Model 
226 Computer, 
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HP-UX: Implementation of UNIX on the 
HP 9000 Series 500 Computer Systems 



by Scott W. Y. Wang and Jeff B. LIndberg 



AN IMPLEMENTATION of the UNIX™ operating sys- 
tem kernel has been layered on top of an existing 
operating system kernel for the HP 9000 Series 500 
Computer Systems. The mapping of UNIX functional re- 
quirements onto the capabilities of the underlying operat- 
ing system is discussed in tliis article, along with the im- 
plementation of UNIX commands and libraries. These 
pieces of UNTK, along with other extensions added by HP, 
maJce up the HP-UX operating system. 

The HP-UX operating system is compatible with Bell 
Laboratories' System Ul UNIX, and supports most of the 
standard UNIX commands and libraries. A number of ex- 
tensions are available, including 

■ FORTRAN 77 

■ HP Pascal 

■ C 

■ HP's AGP three-dimensional and DGL two-dimensional 
graphics subroutines 

■ LAN 9000, an Ethernet-compatible lOM-bit/s local area 
netw^ork 

■ The vi visual editor 

■ Virtual memory 

■ Shared memory 

fl HP's IMAGE data base management system 
m Support of symmetric multiple CPUs. 

HP-UX Operating Environment 

Thure are three levels of software in a UNIX system: 
commands, libraries, and kernel intrinsics (Fig. 1). The com- 
mands are user-level programs which can call libraries or 
kernel intrinsics. Some commands are provided with the 
operating system as standard utilities. One example is the 
command interpreter, or shell Comnnands can also be writ- 
ten as normal user programs by the user. Libraries are also 
user-level code^ but can be called only from a programming 

UNIX hs a U S iradsm^tk oi BeH Ubarslorjes 
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language such as FORTRAN or C Kernel intrinsics can be 
called (normally as functions) from user programs or li- 
braries, and provide a fundamental set of operating system 
operations. 

UNIX Kernel Overview 

A standard UNIX kernel provides support for i/0» file 
system access, process management, real-time clock access, 
memory!' allocation, etc. The set of kernel intrinsics is fairly 
small and simple; only basic operations are supported by 
the kernel. For example, file manipulation operations such 
as copying files are done by commands. The command 
interpreter shell is another capability that is implemented 
in a user program instead of inside the kernel. 
Process Managements The UNIX kernel supports the crea- 
tion of asynchronous processes that run in the background 
while the user executes other interactive programs in the 
foreground. Intrinsics are provided for the creation, termi- 
nation, and synchronization of processes. Special events 



Fig, 1 , UNiX consists of ihrse levels of software — commands, 
tibraries. and kernel intrinsics. 



Typical HP-UX Commands 


Commands in HP-UX 


are run by enlehng the name of the 


command, For instance, to list the contents ot the current working 


directory, enter ts, This causes a program by that name (which 


may be located jn one of 


se vera 1 d ef au 1 1 d i rectorres ) to be loaded 


into memory and to begin executing. Other examples of HP-UX | 


commands are: 




cddiipath 


Change the working directory to the 




directory indicated by dirpatti 


pwd 


Prints the fuii path name (fitename) of 




the current working directory 


vilfiename 


Invoke the visual editor to edit file 




trlename 


rmfiFename 


Remove tile filename 


cp filename destdir 


Copy fi le filename into directory destdir 


cat riEename 


Print the contents of file filename 


calfffenamelwc 


Print the number ot lines, words and 




c hara cters con tai n ed i n f i J e filename 




wc i s the word count comma nd a n d its 




input, in this case, is the output of the 




cal command (due to the pipe created 




byi). 


Is-I 


List the contents of the current work- 




ing directory The - 1 is an option 




that tells the Is command to emit 




additional information Most com- 




mands accept one or more options. 




'Mich&et L Connor 
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are noted by sending signals to 011& or more processes from 
other processes or from the kernel. The kernel manages 
identification fields, such as process ID, user ID, and group 
ID, which uniquely identify a process or group of processes. 
The exec intrinsic loads a user program (code and data] 
into memory from an executable file. The memory model 
of UNIX is very simple* It consists of the user's program, 
an execution stacks and a dynamic heap which can he 
extended or contracted via a kernel intrinsic. 
File Manipulalion. The UNIX file system is huilt around 
a hierarchical director}^ structure, allowing a directory to 
contain other directories as well as normal files* Kernel 
intrinsics are provided to create files, directories, and spe- 
cial files (devices that are in the filename space). The kernel 
also supports creating and deleting Units (alternate names) 
to files and getting or setti ng file access modes- A significant 
feature is the ability lo mount a separate disc volume logically 
onto a directory in an on-line volume. This means that all 
on-line volumes are part of a single directory hierarchy. 
File Access* A single set of I/O intrinsics provides transpar- 
ent access lo files , devices, or the standard input of other 
processes. A program normally does not know whether its 
standard input is coming from a file, a device, or another 
process via an interprocess pipe. Standard operations are 
provided, including read, write, open^ close and status* 
Special device control is provided via the iocti intrinsic* 
Miscellaneous. Several other features are supported hy the 
standard UNIX kernel, such as real-time clock access, log- 
ging accounting information at process termination, and 
profiling the execution of user programs. The profiling and 
accounting facilities have not yet been added to HP-UX. 

SUN Operating System Kernet 

When the HP 9000 project began, the operating system 
designers took a different approach from that used on HP's 
previous desktop computers. Even though the first HP 9000 
language system was to be an extension of the BASIC lan- 
guage system of the HP 9845 Computer, an objective of the 
operating system design was to allow other languages in 
later versions of the product. The system software vi/as 
designed in a modular, layered fashion (see Figs. 2 and 3 
on pages 4 and 5). A central operating system kernel provides 
a high-level interface to the hardware and machine architec- 
ture, while other subsystems provide more specific func- 
tions layered on top of this kernel. This operating system 
kernel, called SUN, is described in detail in the article on 
page 28. 

SUN is written mainly in MODCAL, an enhanced version 
of Pascal. MODCAL supports information hiding* via mod- 
ules, an elegant error recover}^ mechanism, and systems 
programming extensions such as absolute addressing. A 
small part of SUN is written in assembly language. The 
SUN kernel is not visible to the user; instead, it relies on 
upper-level subsystems such as BASIC or HP-UX to provide 
a user interface. The major pieces of the SUN operating 
system kernel handle power-on initialization and memory 
and process management, and coordinate the file system ^ 
drivers, L'O primitives, real-time clock, and interprocess 
messages, 

'informajian hfedSng Is a software d.esjgn approach where the irinerworkin:gsof an mdrv^dual 
Bectjon are Kepi "tiicfden" trom other seclicw'is. This ailcws 3 section to be changecf or 
updated with mimnnal concern about its effects on other sections. 



An unnsual feature of the file and I/O system is the ability 
to add new directory format structures, device drivers and 
interface drivers. These modules can be added withont 
affecting the existing SUN kernel code. 

Some key pieces are missing from SUN by design, notably 
the human interface and program loader. The BASIC sys- 
tem provides its own human interface code, which uses 
the integrated CRT and keyboard of the Model 520. the 
desktop version of the HP 9000 Series 500 Computers. HP- 
UX provides a terminal-style human interface to communi- 
cate wnth die user through the integrated CRT and keyboard 
as well as through normal terminals. HP-UX and BASIC 
also provide their owm program loading facilities. 

HP-UX Kernel Strategy 

The basic strategy of the HP-UX implementation is to 
layer the liP-UX kernel definition on top of the SUN kernel. 
The exact System ID UNIX semantics and syntax are kept, 
but the HP-UX intrinsics axe implemented using SUN ker- 
nel support instead of porting the BeO Laboratories kernel 
implementation to the Series 500. 

A layer of code called the HP-UX layer resides jnst above 
[and in some cases beside] the SUN kernel, as does the 
BASIC subsystem. However, BASIC and HP-UX are mutu- 
ally exclusive; only one can be loaded at a time. 

The HP-UX layer performs any necessary transforma- 
tions between UNIX formats and the corresponding SUN 
formats [e.g., the real-time clock format). It calls procedures 
in SUN whenever appropriate, but still has full access to 
the hardware and architecture when needed. The HP-UX 
layer maintains a number of higher-level data .structures 
to manage HP-UX user processes and user resources. 

This layering strategy has a significant impact on the 
implementation detail of the HP-UX layer. For example, 
MODCAL is used instead of C as the implementation lan- 
guage. However, user-level code written for System III 
UNIX will run on HP-UX, unless it depends on certain 
internal implementation details such as the directory for- 
mat structure or invisible internal system data structures. 

The advantages of this layering approach come in two 
main categories — leverage and opportunities for contribu- 
tion. A large portion of hard ware -de pendent code was al- 
ready written for the Series 500 and its peripherals. Using 
the SUN kernel made it unnecessary to rewrite this code 
for HP-UX. Existing modules used include device and in- 
terface drivers — especially significant because of the com- 
plexity of the HP-IB (IEEE 488] and the new HP CS-80 
discs — low-level memory management, power-up code, 
process scheduler, architecturally dependent utility rou- 
tines, and other machine-dependent code. 

SUN has a number of features that are not present in 
UNIX; these features provide opportunities for 
HP-UX to make a contribution over other UNIX implemen- 
tations. These Lnclude real-time performance in the area 
of interrupt response time and process switching, support 
for multiple CPUSj reliability in the face of system errors, 
support for variable-size independently managed dynamic 
memory segments, semaphores, and low-level device I/O 
capability. Also, HP's IMAGE data base management sys- 
tem was already implemented on top of SUN for the BASIC 
system. This code was ported to the HP-UX enviroiunent 
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What is UNIX"? 



The poputanty of the UNIX'* operating sysiem developed by 
Bed Laboratories has been increasing since rt became opera- 
tionat in 1971 Today, it is rapidly becoming ihe most popular 
operating system tor mid-sized computers and mns on numerous 
rrachines made by ditfereni manufacturers There have even 
beefi those that have likened UNIX s rote m operating systems 
today to FORTRAN'S role in computer languages some twenty 
years ago. 

UNIX was developed by Ken Tt>ompson and E3ennjs Rttchie 
of Bell Laboratories. Both men had been working on a project 
called Multics {an acronym for multiplexed information and corn- 
put tng service), which was a large murtiuser operating system 
that was eventually cancelled by Bell Laboratories From there, 
Thompson, and then Richie, went on to develop UNIX As you 
might expect, many of the more desirable features found in Mul- 
tics were incorporated m the UNIX design In fact, even the UNIX 
name was adopted from a playful twisting of "Multics " 

As the years went by, the UNIX systems within Bell Laboratories 
evolved until version six fV6) was developed about 1 975 This 
version became quite popular in a number of universities around 
the world, including the University of California at Berkeley (UCB) 

Version seven was released in 1 978 and quickly replaced V6 
in most installations This version is the base tor most of the 
commercial UN EX look-alikes, of which the Xenix system de- 
vetoped by Microsoft is probably the best known It is also the 
version on which UCB built their popular enhanced versions of 
UNIX. Each UCB version released contained a few enhance- 
ments over the previous releases UCB's versions are designated 
by xBSD, where x is the version number and BSD stands for 
Berkeley Software Distribution 4 2BSD is the most recent. 

In early 1982, Bell Laboratories released System III UNIX, This 
version is the base for HP-UX (HPs version of UNIX), although 
HP-UX also incorporates some of the nicer features found in 
UCB's 4.1 BSD version, 

System V UNIX was released by Bell Laboratories in 1983. 
Bell IS guaranteeing that all of their future UNIX versions will be 
compatible with System V 

UNIX Popularity 

Exactly why UNIX has become so popular is a hard question 
to answer, but the reasons probably include: 

■ Simplicity The UNIX system can be broken into fairly small 
independeni pieces. Each piece can be comprehended indi- 
vidually and at a pace Ihat is comfortable for a user. Few users 
ever need to learn all the features provided by UNIX. 

■ Power The pieces of the sysiem can be connected synergis- 
ticatly and manipulated at execution time, the I/O can be redi- 
rected, the output of one process can be connected to the 
input of another (forming a "pipeline ' of arbitrary length), pro- 
cesses can be executed in foreground or background, a com- 
mand list can be developed and then executed when desired 
and as often as desired, etc 

m Flexibility, Pieces of the UNIX system are easily added, re- 
placed, or deleted, System reconfiguration is quick and 
straightforward, 

■ Software Bell Laboratories. Hewlen-Packard, and a lot of other 
companies and individuals have put a lot of effort into develop- 
ing a large software base that runs in the UNIX environment. 

UNIX Ifi & U.S. tmdmrmk ot Bell Uboraioiia^. 



■ Ease of porting. Most of the UNIX sysiem !S wntten in a 
machineHndependent manner It has tjeen ported lo a nu^r^ 
ber at different computer architectures with relatively few 
problems 

UNIX has many features. Some of them are: 

■ The shell. The shell is a program that provides the interface 
tietween the user and ttie UNIX system It is a command in- 
terpreter that takes input from the user and executes the re- 
quested commands. It can also take rnput from an ASCII com- 
mand file, which is generally referred to as a "shell script.'' 
When a command is executed, it can be passed arguments, 
have its standard I/O files redirected, and/or be placed in the 
background, alt through provisions built into the shelf The 
shell also has flow control structures that allow conditional and 
multiple execution of command lists Because of the flexibility 
of UNIX, the shell can be replaced by a different program In 
fact. UCB has chosen to do just that and provides their own 
version of the shell called the C shell - 

■ The C Language. C was developed concurrently with UNIX 
at Bell Laboratories. It is a medium-level language with many 
of ihe features found in Pascal and other high-le^el languages 
It provides a programmer with a lot of power and few con- 
straints . Most implementations of the UNIX kernel and most 
of the UNIX commands are written in C. 

a Other languages. Currently HP-UX on HP's HP 9000 Series 
500 and Series 200 Computers offers compilers for Pascal 
and FORTRAN 77 in addition to C. 

a Full set of commands. Commands to maintain the UNIX system 
and the file system, editors, text processors, and numerous 
other commands are included in HP-UX. The popular vi editor 
from UCB is included in this set. 

• A rich set of library routines. These include routines to compute 
common math functions, to perform formatted I/O, to access 
kernel intnnaics, and, on the HP 9000 Series 500 Computers, 
routines to manipulate virtual memory objects, to do DGUAGP 
graphics, and to access an IMAGE data base 

■ Data communication support. System III and other versions 
of UNIX provide a set of UNlX-to-UNIX copy (uucp) services 
to allow the user to pass files from node to node in a UNIX 
network A sophisticated electronic mail system has been im- 
plemented by using these services. To these, ihe HP 9000 
Series 500 Computers add a local area network (LAN 9000). 
general terminal emulator capabilities, and remote job entry 

■ Source code control system (SCCS). This is a set of commands 
that helps the programmer keep track of changes to source 
files. 

Further Reading 

1 H WcG.iCQTi and R. Morgan , fntfoductng (he UNIX Syst&n, McGraw-Hill. 19B3- A 
good lutonai 

2 R Thomas and J Yaies, A User Guftte to rft$ UNiX Sys/em. OSBORNE/McGraw HiEl 
Berkeley, 1^B2. Anolfier good lyrorLal 

3 Be/; System Techmcaf Joumat. Vol S7. no 6. Part 2. July-AuQuel 1978 The entire 
fssue IS dedtcated to UMIX ot sboij} version seven 

A HP^UX fletefence MBnu$(. Hewleti- Packard Pubiicaiion OdOOO-aOOCW. A good refer- 
ence, but not easy lot a novice to understand 

5 HP-UX S&fected Artides. Hew^en-P3ckaTcl Rutalication 970e9'9CO02 Wineteen arti- 
cles on same oi the targe compori^ihis foufyd ih UNIX 

6 S R Bourm, Tha UMX System, Aritlrson^WesJe^, 19S3 A good introduction. 

-Michael L Connor 



MARCH 19&1 HEWLETT PACK ARO JOURNAL 9 



)Copr. 1949-1998 Hewlett-Packard Co. 



to provide this important HP standard data base capability- 
An important concern was the performance of a layered 
implementation; the risk was that conversion between the 
SUN format and the HP-UX format wonld increase operat- 
ing system overhead. The experience actually observed 
after the product was completed was that the HP-tJX layer 
itself is responsible for approximately 10% of tlie CPU time 
used by the kernel, and nearly all of that time is spent 
doing useful work such as loading programs. This means 
that SUN is a fairly good match for the HP-UX requirements, 
because little time is wasted on conversion between SUN 
and HP-UX formats. 

Matching SUN and HP-UX 

This section describes the areas of the SUN operating 
system that were changed or augmented to support the 
requirements of HP-UX. Only areas that are important to 
mapping the UNIX semantics onto the original SUN kernel 
are described in depth. 

File System, There was already a good match between the 
SUN operating system and HP-UX in the hierarchical direc- 
tory structure of the file system. The existing directory 
format was modified to fit HP-UX semantics rather than 
implement the standard UNIX disc format m MODCAL. 
The fundamental operations such as read, write, open, and 
close w^ere already supported in a satisfactory manner in 
SUN; no significant changes to these were necessary. 

However, the file system itself was the area that required 
the largest changes in SUN. One of the biggest additions 
was the support of device files, special files that map de- 
vices such as printers or terminals into the same name 
space as regular files. The SUN file system expected device 
and file accesses fo be made separately, Speciai checks had 
to be made for special file types; the new device file code 
performs operations for device files equivalent to those 
originally performed only for regular files. 

Another large change was support for mounting disc vol- 
umes onto an on-line directory so that all accessible files 
and directories are part of a single directory hierarchy. 
Again, special code was added to check each directory 
access; if the directory has another volume mounted on it, 
the access is redirected to the root directory of the mounted 
volume. 

The third area of major change was file access protection 
semantics. The UNIX read/wTite/execute and user/group/ 
other mechanisms used to control access to files were not 
originally in the SUN file system protection scheme. This 
could have been added, along with the standard UNIX disc 
format structure, to a separate directory format module, 
since SUN supports multiple directory formal structures. 
However, the characteristics of the existing format were so 
close to those desired that the SUN format and protection 
scheme were adapted to the HP-UX requirements instead. 

Changes were made in the SUN file system to support 
pipes and FIFO [ftrst-in, first-out) files. In the early versions 
of HP-UX, pipes were implemented in the HP-UX layer. 
However, they have been moved inside the SUN file system 
for performance reasons. A number of minor HP-UX file 
system operations had to be added to SUN. These include 
changing the owner of a file, reading or changing file access 
modes, and duplicating an open file descriptor 



Some operations are performed in tile HP-UX layer. 
These inckide parsing multilevel path names, managing 
the user's open files table, and enforcing file size limits on 
extending files. 

1/0, In the area of device I/O, the existing SUN I/O system 
was a very good match for the needs of UNIX, Virtually no 
changes were made to the I/O primitives that provide the 
interface to the backplane and I/O processor, the bus 
bandwidth management code, the drivers for interface 
cards, or the disc and tape device drivers. 

The major changes came in the internal and external 
terminal support. The external terminal driver is based on 
the existing serial interface driver, but adds UNIX tty seman- 
tics such as type-ahead, line buffering, mapping carriage 
return/line feed to new line, and sending the interrupt and 
quit signals. The Model 520 Computer's integrated keyboard 
and CRT device control code is based on the work done 
for the BASIC system's human interface. But the functional 
operation of the integrated "terminer' had to be completely 
redone to be compatible with HP terminals. 
Memory Management. Because of the simple memory 
model of HP-UX, the memory allocation intrinsics are eas- 
ily supported on most operating systems, including the 
SUN kerneL The major changes in the SUN memory man- 
agement system w^ere required by the addition of virtual 
memory and shared memory, which are extensions rather 
than semantic: requirements of UNIX. The HP-UX layer has 
the responsibility of keeping track of the user's memory 
use and deallocating this memory when a process or pro- 
gram terminates. 

Program Loading. No explicit function for loading and 
executing programs is present in the SUN operating system, 
but the underlying support needed is there> The file system 
is used (with minor changes) to find and read the program 
file» and the memory management system provides the 
mechanism for allocation of code and data segments. No 
major changes were required in the SUN kernel to support 
program loading. 

The HP-UX layer manages shared code segments, which 
allow multiple processes to share a single copy of the code. 
The HP-UX layer also handles relocation of code and data 
segments at load time and meets the segment attribute re- 
quirements requested by the object file format. 
Process Management. The flP-UX process management in- 
trinsics are supported fairly well by the SUN kernel, but 
tw^o areas required a significant effort: fork and signal. The 
fork system call creates a new process in the exact image 
of the calling process. It returns to both the parent and 
child processes, just after the fork call, at the point where 
the function return value distinguishes the child from the 
parent. Creating an exact copy of a process is not a typical 
operation supported by normal operating systemsn includ- 
ing the SUN kernel. 

At the SUN level, code was added to support the "clon- 
ing'' of a process. The cloning operation allocates memory 
for the child process and initializes SUN modules for the 
new process. It is also responsible for duplicating the con- 
tents of the parent's segment table in the child's segment 
table and creating an exact image of all the parent's seg- 
ments in the child's address space, including virtual mem- 
ory segments and the stack segment. 
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The HP-UX layer then initializes the new process. This 
includes allocating an HP-UX process control block, copy- 
ing some fields from the parent's process control block, 
and initiaiizing other unique fields such as process ID and 
parent process CD, It also increments use counts on shared 
ob|ects such as shared code segments and open files. Fi- 
nallvt ihe HP-UX layer returns the appropriate value to the 
parent [child's process ID) and to the child (zero). 
Signal iinplementation. The implementation of signal, a 
mechanism for interprocess event notification and excep- 
tion reporting^ was a significant portion of the HP-UX layer 
development. SUN had no explicit support for sending 
asynchronous signals between processes, but did have most 
of the tools necessary to implement this feature. 

One tool is the ability of subsystems to install trap han- 
dlers for most classes of traps possible on the Series 500 
Computers, Signal processing is initiated by triggering an 
Ml (machine instruction) trap in the target process, which 
causes the Ml trap handler to be entered on the next machine 
instruction executed. This handler is responsible for pro- 
cessing the signal received and taking the specified action. 
This can be calling a user-specified signal handler, ter- 
minating the process, or just ignoring the signal. 
Other Process Management The process scheduler met 
the requirements of HP-UX in the original SUN implemen- 
tation, but has been improved to allow dynamic process 
priority adjustment to reward interactive processes. (It is 
currently being enhanced to suspend low- priority pro- 
cesses during heavy system loads.) SUN supports the cre- 
ation of special system processes that can provide specific 
system services. These system processes communicate 
with user processes and each other via SUN's mailbox-style 
interprocess messages. Also, a sophisticated set of 
semaphore operations is provided for synchronization of 
all processes in the system. This is especially important in 
a muhiple-CPU system: merely disabling interrupts does 
not ensure exclusive access to a shared data structure, be- 
cause other processes may be running simultaneously on 
other CPUs. 

The following process management functional areas are 
implemented in the HP-UX layer: 

■ Higher-level support of fork such as allocation and in- 
itialization of a process control block for the new HP*UX 
process 

■ Higher- level support of signaJ, including sending and re- 
ceiving signals, and specifying action to be taken on 
receipt of a signal 

■ Management of user* process » and group IDs 

■ Process termination, including deallocation of resources 
ow^ned by the user process 

■ Wait for a signal or for termination of a child process 

■ Management of HP-UX process control blocks. 

The functional areas listed below are completely sup- 
ported by the SUN kernel » except for those changes noted. 
• Power-up 

■ Multiple-CPU support 

■ Trap handling 

■ Real-time clock: the HP-UX layer performs the conver- 
sion between SUN time format and HP-UX time format 

■ Alarm clock: the HP-UX layer creates a system process 
that wakes up each second to see if any alarm signals 



need to be sent 
■ CPU times: a minor change was made to the timer inter* 

rupt service routine to increment the CPU time used by 

the current process. 
Upper-Level Software Strategy 

Working in parallel with the SUN and HP-UX kernel 
design groups was another group of software engineers 
who %vere responsible for the upper- level commands and 
libraries. The UNIX system from Beli Laboratories contains 
more than 300 commands and over 200 library subroutines. 
Consisting of more than 300,000 lines of C source lines, 
these constitute the bulk of the UNIX system. The majority 
of HP-UX upper-level software on the Series 500 Computers 
is based on these UNIX System 111 commands, plus several 
from the 4.1BSD version of UNIX from the University of 
California at Berkeley (UCB). 

For implementation priorities, the upper-level software 
team first categorized the commands and libraries into dif- 
ferent groups based on their usefulness. For example, in* 
itialization and file manipulation commands were all in 
the first group. Useful tools were in the second group and 
other commands and librarieSn such as those used for text 
processing, were in the third group. Then the C source 
code of the first two groups was studied in some detail 
using a C cross referencerlo determine which system intrin- 
sics and libraries were used. The data resulting from the 
study was stored in an fiP 9845 IMAGE data base from 
which many useful reports were produced. For example* 
a system intrinsic implementation priority list was gener- 
ated based on the highest-priority commands to guide the 
kernel group in their implementation. As new system in- 
trinsics were brought up, the upper- level software team 
was able to determine from the data base what additional 
commands could be brought up with the newly available 
intrinsics. 

Another IMAGE data base was used to keep track of all 
commands and libraries in terms of implementation prior- 
ity, responsible engineer, porting status, source origin, etc. 
This proved to be very useful for managing the project and 
keeping other departments informed about the .status of 
each command. 

Porting Commands and Libraries, Four major tools were 
necessary to port the upper-level software: a C-to-HP-9000 
cross compiler, an assembler, a linker, and a cross compi- 
lation machine. The upper-level software team used a re- 
motely accessible VAX/750 running UCB UNIX as the cross 
compiling environment. Other tools to move files to and 
from the VAX/750 were developed as necessary. 

After the initial system was up and running, the major 
focus was to make the C compiler resident on the Series 
500 by cross compiling it. We had a resident environment 
two months later. From that point on, all development 
work was done on a Model 520 Computer running the 
latest (sometimes experimental) kernel. The upper-level 
software development system then grew from one single- 
user system to two multiuser systems linked with a local 
area network- 

The majority of the commands and libraries were ported 
over to the Series 500 with little or no modification, that 
Is. most of them ran after compilation. However, the follow- 
ing types of changes were necessary. 
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HP-UX: A Corporate Strategy 



With the introduction of HP-UX on the HP 9000 Series 500 
Computers, Hewlett- Packard has made a strong commitment to 

the use of an enhanced version oi UNIX™ as a standard operating 
system for its new computer products. Through this commitment, 
HP is striving to eJiminate unique software attributes that mal<e 
end-user programs difficult to "port" from one computer to 
another. Programmers can now design their software to run on 
an array of HP machines, concentrating on modulanzing and 
scaiing their applications to best suit each computer's price/per- 
formance characteristics. 

Why UNIX? 

Since any operating system standard would simpiity the porting 
process and improve programmer productivity^ why was UNIX 
selected as the heart of HP's software strategy? 

UNIX is gaining wide acceptance as an industry standard for 
16-blt and 32-bit minicomputers. Its popularity is partially be- 
cause it has been easy to implement on a vahety of processors 
and computer architectures. This portable characteristic made 
UNIX an ideal choice as a compatible operating system for the 
dfstinct archftectures of current HP 9000 members: the 16/32-blt 
68000 microprocessor- based Series 200 Computers (Models 
220 and 236) and HP's proprietary 32-bit VLSI-based Senes 500 
Computers (Models 520, 530, and 540). UNIX is also planned 
for future members of the HP 9000 family, 

The popularity enjoyed by UNIX has a synergistic effect. Soft- 
ware applications are being designed for the UNIX environment 
at an increasing rate, which in turn encourages more UNIX im- 
plementations. Most of this software will run on HP-UX. thereby 
making HP's computers more attractive to a larger audience. 
Furthermore, UNIX is studied and taught in most major univer- 
sities. Today's computer science graduates will eventually influ- 
ence or become those who select computers for commercial 
and scientific use. UNIX-based products are likely to receive 
strong consideration during the selection process. 

What is MP-UX? 

HP-UX is a combination of Bell Laboratories' UNIX operating 
system, portions of the University of Caiifornia at Berkeley (UCB) 

UNIX is. a U.S. trademark pi Sell Laboratones 

•Kernel. Libraries 
•C Compiler, vi 
•Other Commands 
•(System V Semantics) 



•System III Kernel, Libraries, 

and Command 
•(System V Semantics) 



•Graphics, Games 
•Experimental Functions 
•Seldom -Used Functions 



Key: 

( ) Definition in 
progress 

Not HP-UX 



implementation o1 UNIX and Hewlett-Packard software enhance- 
ments. Hirough UNIX, HP-UX facilitates easy importation of UNiX- 
derived programs and offers a consistent, pov^erful program de- 
velopment environment. Complementary extensions address the 
Manufacturer's Productivity Network (MPN). HP's view of how 
compuier systems can be used in manufacturing organizations 
to improve productivity. 

Rather than implementing every function of Beli Laboralories' 
System ill UNIX, features were included based on their impor- 
tance in porting standard software or their absolute program 
development value. Using these guideiines, a compatibility 
hierarchy was developed in which Kernel services became a 
'must, " library subroutines a "high want," and commands a 
"want." 

As a result of this approach, HP-UX includes all System ill 
kernel intrinsics and all libraries except for a handfui of graphics 
subroutines. More than 125 of the most useful System III com- 
mands and a small but important number of UCB commands 
are also offered, 

To satisfy customer requirements, enhancements covering 
programming languages, graphics, data base managemem, de- 
vice and instrumentation 1/0, local area networking, and friendly 
user interfacing are being standardized. These extensions, which 
appear as additional kernel intrinsics, libraries, and commands, 
will bridge the gap between HP's HP-UX and non-HP-UX computers. 

Additional enhancements assist in migrating applications soft- 
ware from current proprietary HP operating systems to HP-UX, 
One of these tools, the Applications Migration Package (AMP), 
converts the HP 1000 Computer's RTE calls to HP-UX calls. AMP 
revisions are planned as HP-UX is expanded to meet real-time 
control requfrements. 

New software features are not the only form of HP enhance- 
ments. On-going training allows sales and technical support or- 
ganizations to provide complete services before and after sales. 
Easy- to-read tutorials and reference manuals aid both novice 
and experienced users. Exhaustive R&D software testing ensures 
reliable operation and minimal downtime. 

Since HP-UX is planned for many future HP compulers, HP 
will leverage investments already made in these important sup- 
port areas. By avoiding the massive reinvestments continuously 
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Fig, 1. Influence of Belt Lab- 
oratories, UCB. and HP exten- 
sions on the direction of the HP-UX 
definition. 
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require of new software systems, HP can oorvcentrate on impfov- 
ing all aspects of HP-UX in tie future. 

W-UX Standanfft Enforcement 

Compliance with the HP-UX standard ts enforced through com- 
prehefisive sets of validation programs. Automated test programs 
monitor proper operalion of all kernel inirins^cs. System III li- 
braries, twoHdfmensional and three-dimensional graphics li- 
brafies. and the FORTRAN and Pascal compifers As the stan- 
dard evolves, additional validation programs will be developed 
to ensure consistency across all HP-UX computers. 

Ovefall mar^gement of the standard is the ongoing responsr- 
bility of the HP-UX Steering Committee Consisting of represen- 
tatives from several HP divisions, ttiis committee meets monthly 
to resolve pertinent HP-UX issues and to review the status of the 
various HP-UX workjng groups. These groups, also with broad 
divisional representation, cover technical marketing, documen- 
tation, and customer support issues in more detail Each division 
works through its representatives to propose additions or 
changes to the standard, 

FyturB Direction 

Perhaps the most critical issue in establishing the future course 

for HP-UX IS its degree of compatibility with Sell Laboratories 
and UCB, While 4.2BSD UNIX (Revision 4.2 Berkeley Software 
Distribution) is currently the superior version. Belt fs developing 
improved versions that could eventually surpass 4.28SD in capa- 
biiity and reliability In addition, four microprocessor manufactur- 
ers* intend to offer System V, Bel Is latest UNIX version, on their 
microprocessor products. System V can potentialiy become the 
most affordable UNIX and thus the UNIX of choice for portable 
application programs. 

*lrKtBl. MoTorola. Natiorrai S^miccinducior. and Zilog 



In consjderatton of ihese factors, the Bell System Ifl version 
has been chosen as the base standard. The compatibility hierar- 
chy wll determine which portions of Syst^n V and its successors 
are HP-UX candidates 

Extensions t>eyond the Bell versions can be expected if they 
fafi 10 meet HP requirements in a timely fashion However, we 
prefer to adopt an existing UNIX-based implen^niatton {if one 
exists) before embarking an an original design project A poten- 
tially rjoh source of enhancements currently under tnvestigation 
IS UCB's 4 2BSD vers ton. We anticipate adding such UCB fea- 
tures as the C shell, mailer, and selected kernel intrmsics. 

Microsoft's Xenix, with its large installed base and potentially 
hch source of UNIX ^plications programs, coufd influence the 
HP-UX standard. Since Xenix and HP-UX are selectively adding 
Bell System V and UCB features to the same System 111 definition, 
Gontomnance between the two systems is likely. 

Fig 1 illustrates the major influence of the HP extensions and 
the Bell releases on the HP-UX direction. It also recognizes UCB 
as a promising contributor of additional functionality. 

In support of low- cost computer systems, we are examining 
methods of subsettrng HP-UX without sacrificing compatibility or 
easy growth to the higher-performance systems Code compac- 
tion and reduction techniques for both the operating system ker- 
nel and the disc resident commands are being considered, An 
exciting technique under investigation is a hsgh-performance dis- 
tributed HP-UX operating system, which allows individual work- 
stations to rely totally on shared network peripherals. Thus, the 
cost per system is dramatically reduced, but [ocal processing 
power is maintained. 

HP-UX will be modified to support several European languages 
and the i6-blt Kanji character set. Thus, localized application 
program solutions will be possible. 

-Michael V. Hetrick 



A new system intrinsic entry point mechanism was de- 
veloped because the kernel was written in MODCAl. and 
the rest of the system was in C. 

Some data structures contained in the C header files 
needed to be modified to match the HP-UX layer data 
structures. (Header files contain data and structure decla- 
ration statements for C programs.) The commands that 
needed these header files were examined in detail to see 
If modification was necessary, 

A few commands were rewritten completely because the 
kernel was not the original standard kernel. For example, 
fsck, the file system integrity checker and maintainer. 
was rewritten because tJie SDF (structured directory for- 
mat) file system^ is physically different from the UNIX 
file system. The process status command ps was modified 
extensively because of data structure differences* 
Another example was the mknod command which creates 
special files to communicate with I/O devices. It was 
modified to match the UNIX semantics to HP-IB 1/0 de- 
vicesn However, all the commands were kept as compat- 
ible as possible with System III UNIX commands- 
The Series 500 supports IEEE floating-point format; as 
a result, the UNIX math lilirary was replaced with HP's 
own implementation- 

Twenty-one new commands were implemented that 
apply to the Series 500-based HP-UX. These deal primar- 
ily with machine-dependent features such as disc boot 
area management, disc initialization, setting virtual 



memory parameters, and system installation and update. 

The handling of DC600 tape cartridge data on HP's new 

CS-80 discs also required special support. 
Problems During Porting, The problems encountered in 
()f3rtmg the commands and libraries can be categorized in 
two areas — architecturally dependent and architecturally 
independent. Architecturally independent problems were 
mostly anomalies found m the original UNIX code. We 
logged over 281 new bug reports during the port project* 
Over B0% of these bugs were fixed. The others were either 
classified as not worth fixing or waiting to be fixed. 

Architecturally dependent problems were usually 
caused by dereferencing of nil pointers or dependency on 
the direction of stack growth. Oti the VAX/ 750 implemen- 
tation of UNIX, a nil pointer dereference returns a zero. 
On the HP 9000 Series 500 HP-UX, a system trap occurs. 
This architectural dependency is relied on in many places 
in the standard UNIX commands and libraries, and each 
of these needed to be corrected. These usually manifested 
themselves in a memory fault error message. Fortunately, 
this error was relatively easy to fix in the source code. 

The stack grows towards high memory (up) on the Series 
500 and down on Ihe VAX/750. For example, the printf suh- 
rouline In the standard I/O library can have a variable 
number of parameters and the pointer used to access the 
parameters on the stack is decremented rather than in- 
cremented. Other architecturally dependent features in- 
cluded the byte order swap of the VAX.^750 hardware where 
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!ow and high bytes are reversed. This made reading cpio 
archive format tapes from the VAXy750 a chore in the be- 
ginning. Now HP-UX defines a new -p option to the cpio 
command which does the byte swap. 

The upper-level software team did not have a user-level 
debugger available to debug the C programs. Instead^ the 
kernel-level HP 9000 debugger was used to debug the com- 
mands. It was cumbersome to set up the initial hreakpointt 
but quite effective after that. (A user-level symbolic debug- 
ger is being dcvelopedj 

Shared Libraries, The Series 500 architecture supports 
shared code segments, thus allowing the implementation 
of a special shared library for major portions of the standard 
C library. That is, there is only one copy of the librar^^ in 
the system shared by all system commands that are linked 
in the standard C library. (The shared library feature is not 
currently available to user programs.) This saved typically 
7K bytes of code space for each command [just about all 
of the commands used the C library^' This, in turn, im- 
proved toad-time performance and saved disc space. 
sees and the Build Process. UNIX is touted as one of the 
best program development environments available, be- 
cause it provides many software engineering tools. The 
source code control system (SCCS) is one such tool that 
the upper- level software team took advantage of throughout 
the project life cycle. The SCCS was brought up and used 
as soon as all kernel support was available- The Bell 
Laboratories System III source code was put under SCCS 
as the baseline and all upper-level software changes were 
built on top of it. Each upper-level software team member 
adhered to a simple set of rules that applied to the access 
and update of the controlled source. This proved valuable 
for day-to-day software development, providing who, 
when, how, and why information about code changes. 

sees maintains revision numbers to allow access control 
and retrieval of any version of the source code, ll also 
supports checksums of the source files to check for corrup- 
tioUn This was important since code development was done 
in parallel with the file system development and the 
checksum is a simple physical integrity check. SCCS was 
indispensable later during quality assurance testing and 
the code freeze period just before each major system release. 

System build scripts were written to manage the compi- 
lation of all the commands and libraries from the SCCS 
source directory automatically. The build procedure, along 
with the scripts, was able to handle compiler, assembler 
and linker updates, getting the source, and compiling the 
system in proper sequence. This was important for system- 
wide changes such as object file format changes or major 
updates in the compiler or other tools. The scripts also 
controlled the target file system structure, setting file own- 
erships, access permissions, etc. They also managed the 
SCCS update revision level of each system build such that 
any change occurring after the build started would be at a 
higher level and would not be included in the current build 
even if the build process had to be restarted for some reason. 
The build scripts evolved through the life of the project 
and became a major tool for system releases. The final build 
of the 3.3M-b3rte system took around 17 unattended hours 
to complete. 



Compatibility 

The upper- level software porting experience indicated a 
high degree of compatibility between the HP-UX layered 
kernel and ihe UNIX System 111 kernel Out of 126 ported 
commands from System 111, 57 required no modification 
at all, 44 required less than 10 lines of modifications, 16 
required between 10 and 30 lines of modifications, and 9 
required more than 30 lines of modifications. Most modifi- 
cations were to fix bugs. These commands do not include 
development tools such as a com^nler, an assembler, and 
a linker, nor do they include UCB UNIX commands. 

Extensive effort was made to ensure compatibility with 
Bell Laboratories' System III UNIX. First, a "minimum 
touch'' strategy on the System 111 source code was used. 
The design team did whatever was necessary to make the 
commands and libraries work, but beyond that they did as 
little modification as possible. Temptations to clean up the 
code were strongly discouraged. Each reported bug was 
evaluated to determine whether it should be fixed and if 
so. how. 

Second, validation suites^ were used to ensure compati- 
bility with System Oh The priority for the validation suites 
was to validate the kernel first , then the libraries, and fi- 
nally the commands. 1007a of the kernel intrinsics were 
validated. A significant effort was invested in the kernel 
validation suite. It was run after each new kernel was built. 
92% of the subroutine libraries have validation tests and 
all are incorporated into an automatic test suite. 22% of 
released commands have validation tests. The validation 
suites were written with verification of the functionality 
in mind rather than exhaustive quality assurance testing. 

The automatic validation test suite is organized for ease 
of use. There are two types of tests — one related to the root 
user* and the other related to the typical user. The automat- 
ic test suites were provided to the software system integra- 
tion team for testing commands and libraries with other 
maior subsystems. 
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An Interactive Run-Time Compiler for 
Enhanced BASIC Language Performance 

by David M. Landers, Timothy W* lillsorij Jack D, Cooley, and Richard R. Rupp 



m T THE BEGINNING of the BASIC project for the HP 
^l 9000 Model 520 Computer, the project team was 
J^^m faced with a major challenge. To take full advantage 
of the performance available in the Model 520 from the 
new 32-bit NMOS-III VLSI microprocessor.^ BASIC had to 
he implemented as a tomprled language- tJsing traditional 
compiler technology, this would mean giving up many of 
the interactive features so popular with current HP 9845 
users. The challenge was to develop a new compiler tech- 
nology that would support these interactive features while 
maiotaining the performance advantage of a compiler. 

The breakthrough came in the form of two articles on 
"throwaway compiling." explained in two articles — one 
by PJ. Brown" and one by J. Hammond/* The throwaway 
or run-time compiling technique compiles each line the 
f i rst t i me it is executed . As more of the program is com piled , 
the performance approaches that of a traditional compiled 
system. If the program runs out of memory, the current 
object code is discarded (hence the term "throwaway com- 
piling") and the incremental compilation is restarted at the 
next line to be executed. 

The authors were looking for a way to run programs 
efficiently on machines with limited memory space, but 
the throwaway compiling technique looked like it could 
be adapted for a run-time compiler that would provide the 
desired interactive features. If the object code could be 
thrown away during the execution of a program and rebuilt 
without restarting, it could also be thrown away at arbitrary 
times such as when the user modifies the program. Withio 
limits, the program reconstructed after throwaway could 
be different from the program before throwaway. This 



would support the pause, edit, and continue feature. Given 
that an intermediate form of the program is available to 
reconstruct the object code at run time, this intermediate 
code could be designed to contain enough information to 
support the interactive debugging features. Finally, if the 
object code could be constructed one line at a time and 
added to the object code at run time, the code for a single 
line could be constructed and immediately executed as 
welL This would allow asynchronous execution of single 
lines from the keyboard during program execution. 

Enhanced BASIC Language 

The BASIC language that Brown implemented as part of 
his research was a very minimal subset » whereas Model 
520 BASIC is a substantial language with several significant 
features beyond those supported by most other BASIC sys- 
tems. Could these more advanced features be implemented 
in a run-time compiling environment? That was the ulti- 
mate challenge facing the design team. Some of the lan- 
guage features that presented the biggest challenge were: 
» Subprograms similar to FORTRAN routines, but support- 
ing recursion. Both subroutine and function subpro- 
grams are supported. 
m A COMMON statement similar to that used in FORTRAN. 
Both blank and labeled COMMON are supported. EQUIVA- 
LENCE is not supported. 
a ON conditions; a mechanism for handling asynchronous 
interrupts within a BASIC program. The interrupt service 
routioes are part of the program, accessible via GOTO. 
GOSUB or GALL statements. Normal program flow can be 
altered at any tine boundary in response to one of these 
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intBrnipts. Examples of possible interrupts include 
keyboard keystrokes, interrupts from I/O devices, soft- 
ware signals, and real-time clock events. 

■ Structured programming constructs such as IFTHEN/ 
ELSE, WHILE and REPEAT loops, and CASE- 

m A REDIM statement that can dynaminally change array 
bounds. 

■ Dynamic variable allocation/deallocation via the ALLO- 
CATE and DEALLOCATE statements. 

User Code Structure 

The internal representation and management of the 
user's progrdm in the Model 520 BASIC system provides 
insight into a complex and fascinating software architec- 
ture. This representation is called the program chain, which 
is a collection of contexts/ each of which represents a 
user-level .subprogram, A context can either be compiled, 
or in a form from which the original source code can be 
reconstructed, called intermediate code (icode). Compiled 
contexts are created using the COMPILE command (not to 
be confused with the code compiled by the incremental 
run-time compiler), and are discussed in greater detail 
below* The icode contexts can be listed and modified at 
the source level by the user; the name comes from the fact 
that the source is represented internally in a form that is 
midway between source and object code. The icode con- 
texts aiso contain the incrementally compiled object code 
produced by the run-time compiler as the program runs. 
Intermediate Code Contexts, An intermediate code context 
consists of two machine data segments: the icode segment 
and the symbol table segment {see Fig. 1). 

The context header holds information that describes the 
context and its relationship to the other contexts in the 
program. Also in the context header is a pointer to the 
corresponding symbol table segment and to the next and 
previous contexts in the program chain. The static object 
code contains many small code sequences needed to sup- 
port running BASIC programs, including code to handle 
ON conditions, end the program, handle input responses, 
and other tasks. This static object code is always there, and 
the incrementally compiled object code branches to it when 
in need of some help for one of these tasks, 

'The readef shaukd t>e aware ihat other articles in thss issue may define the term "cofiteKl" 
di^lferently. 
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Frg. 1 . The Icode context contains two segments a^ shown . 



The formal schema area holds a compact description of 
the parameter list for this subprogram. It describes the 
number and types of the parameters and is useful for sup- 
porting the call linkages. The icode area holds the represen- 
tation of the lines of the user's subprogram. Each line of 
source corresponds to one line of icode. Whenever the user 
modifies the intermediate code, the abject code gets thrown 
away. The intermediate code can then grow or shrink with- 
out having to move the object code. The incrementally 
compiled statement object code is the object code for the 
statements in the context. As the program runs, the object 
code builds up in this area. The segment is extended if 
necessary to make room for more object code. 

The free space contains all the unused space in each 
segment; all the other areas are directly adjacent The object 
code for a keyboard command goes into this area. Since a 
command is a one-time event, and not part of the program, 
the object code for that command disappears after the com- 
mand is executed. If there is not enough empty space to 
hold the command's object code^ the segment is increased 
to make room. 

The segment transfer table holds the pointers to proce- 
dures for calls into and out of a segment. During incremen- 
tal run -time compilation, this table grows and may cause 
a segment extension. 

The symbol table header contains a pointer to the icode 
segment, the total size of the symbol table segment, and 
lengths of items in the symbol table. The symbol table area 
contains a series of entries, one for each identifier in the 
context. There are fields in the entry for the storage organi- 
zation of the identifier (e.g., COMMON and ALLOCATED], the 
identifier representation such as DOUBLE or REAL, the 
number of dimensions (if an array), the type of identifier 
(lab eh numeric variable, subprogram, etc.), the offset into 
the value area of its definition, and the characters of the 
identifier name. If this area has to grow because the user 
enters new identifiers, it moves the prerun object code 
down, extending the segment if necessary. 

The prerun object code allocates space for the local vari- 
ables of the context, and it also initializes any bounds that 
these variables need. This object code does not correspond 
to any program statement; it just sets up the variables that 
the statement object code will use. In BASICt variables do 
no! have to be declared explicitly; new variables can be 
defined by keyboard operations or even by modifying an 
executing program. This run-time implicit variable alloca- 
tion can cause the prerun object code to grow so that the 
new variables can be initialized at the next activation of 
this context. 

The double segment approach facilitates the manage- 
ment of all the dynamic edges. All areas except for the two 
headers must be able to grow. The icode area and the sym- 
bol table area must grow at the same time during parsing. 
The statement object code area and the prerun object code 
area must grow simultaneously during program execution. 
Compiled Code Contexts. The user can compile any context 
currently in memory by using the COMPILE command and 
store the object code in a PROG format file. Two benefits 
accrue from the fact that compiled contexts contain no 
intermediate code. They require less memory when loaded, 
and it becomes possible to release programs without releas- 
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Fig. 2. Machine data segment for compiled code context. 

ing their source. Compiled and icode contexts can coexist 
in the same program. In this case the icode subprograms 
hst normally, while the compiled ones list the source of 
tiieij original context header. These lines begin with 
»»> to indicate that the subprogram code is compiled. 

Since compiled contexts have fewer d\aiamic edges than 
their intermediate code counterparts, they require only one 
machine data segment (see Fig- 2]. 

Icode Format. Each context contains a block of inter- 
mediate code that directly represents the source text of the 
original subprogram. There is one line of icode for each 
line in the source. A line of (code contains a header, fol- 
lowed by a series of tokens that represent kev-^words, 
operators, constants, and symbol table entries. These to- 
kens are of varying length and are generally in the same 
order as the elements they represent in the original source, 
except for express ions , wh ich are i n reverse Pol ish n otat i on 
(RPN). The first byte of each icode token describes what 
type of entry it is and how many bytes the entry takes. 

The combi nat in n of RPN for ex press! ons and source order 
for everything else in the intermediate code may seem 
strange. Since the Model 520's CPU uses a stack architec- 
ture, RPN makes if easy for the compiler to generate optimal 
code for expressions. On the other hand, source order 
simplifies Usting and nonexpression code generation, be- 
cause the compiler can know what kind of statement it is 
dealing with at the beginning of the icode line. 

A line of icode is simply a series of bytes from 11 to 255 
bytes long. There are length fields in each line to allow the 
system to traverse the lines of icode either forwards or 
backwards. This last capability is nseful when scrolling 
backwards in the editor. The system generally refers to a 
line of icode by specif>'^ing its offset in the icode area. 

The objective in the design of the intermediate code was 
to minimize the memory space it requires. Most program 
elements need just a single-byte entry to represejil them. 
For numeric constants, studies have shown that most con- 
stants are small integers. Thus, for integer constants in the 
range f> to 9, single-byte icode entries are used. For the 
somewhjit larger constants (up to 255), two-byte entries are 
used. Constants greater than 255 require five-byte entries. 
Floating-point constants are represented as character 
strings. Most real constants such as 5*3 only have a few 



chai^cters, so storing them as characters takes few'er bytes 
of storage than if they were stored as an eight-byte real 
value. Key\¥OTds are arranged so that the most common 
ones have a single-b^-te icode representation. All other en- 
tries lake either two or three bytes, 

Symboi table entires have two possible forms. In BASIC 
programs » commonly referenced identifiers tend to have 
single-letter names such as I, J, and N, and represent 
numeric variables. Ten special locations are reserved in 
the svTnbol table for this type of identifier, and a special 
single-byte icode entry exists lo represent them. All other 
identifiers need a two-byte icode entry. If there are more 
than ten single-character numeric variables, the first ten 
will use the single-byte representation, and the rest will 
use the two-byte representation. All nonnumeric iden- 
tifiers, such as strings, labels, functions, and subprograms 
always use a tw^o-b>i:e icode representation. 

Two examples of icode program lines for tw^o typical 
BASIC statements are shown in Fig- 3, 

Fundamental Mechanisms 

The run-time compiler is an incremental compiler. That 
is, the program is compiled one piece at a time. In this case 
the unit of compilation is a BASIC program line and each 
line is compiled the firs! lime it is executed. The simple 
program listed tn Fig. 4a illustrates the fundamental 
mechanisms of the run-time compiler. As a programmer 
enters a program, it is translated from the BASIC source 
code to an intermediate code representation as discussed 
earlier. When the programmer presses the RUN key to exe- 
cute the program, the system detects that the first line of 
the program is not yet compiled, so a bootstrap code se- 
quence is emitted to invoke the compiler to compile the 
first line [Fig. 4h) and control is passed to it. Line ID is 
then compiled and the compiler checks to see if the next 
line, line 20, has been compiled yet. It has not^ so a code 
sequence to invoke the compiler for line 20 is appended 
to the end of the code for line 10^ 

This new code overlays the initial bootstrap sequence, 
which is no longer needed (Fig. 4c), and control is trans- 
ferred to the code for line 10, which is executed and then 
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Fig. 3. J\No examples of icode representations of BASIC 
program hnes. 
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(a) Ejcamp^e BASIC program 

10 PftlHt "Table of Squares and Sq,u9r« Rocta" 
ao 1= 1 

30 IF ^ IOC THEN Done 

40 pmm M^:2,SQR(i) 
so t ^ I + 1 
60 GOTO 30 
70Dane:END 

{h) RUN commanci bootstraps to begin execution 



call compllertlO) 



(c) Line 10 compltect 



code for line 10 



(d) Line 10 executed and line 20 



code for lirve 10 
code for fine 20 
"call compllor(30) 



(e) Line 20 executed and tine 30 comptled 



Cdde for FFne TO 

code for line 20 

code for line 30 
test fori 100 
truen call comptter{70) 
fslse: call compll»r(40) 



{fj Line 30 executed (test wss filse) and line 40 compiled 



TOf »n» 1 
code for line 20 
code for line 30 
test for I 100 
true: call compller(70) 
ral$0: code for Ifne 40 
call compllerf^O) 



follows through to invoke the compiler for line 20* Simi- 
larly, line 20 is compiled (Fig. 4d) and executed and the 
compiler is called to compile line 30. After line 30 is exe- 
cuted, there are two different lines that may be executed 
next, depending on the results of the IF test. Therefore, the 
compiler emits code to invoke itself for both lines 40 and 
70, and the IF test will branch to one piece of code or the 
other (Fig. 4e). Because the initial value of I is 1, the test 
is false the first time line 30 is executed, so the compiler 
is called to compile line 40. Lines 40 and 50 are compiled 
and executed (Figs, 4f and 4g) and the compiler is then 
invoked to compile line 60. 

Line 60 is an unconditional transfer of control to line 
30, which the compiler realizes is already compiled. There- 
fore, a branch instruction to the code for line 30 is all that 
is emitted for line 60 [Fig. 4h)- The main loop in the program 
is now entirely compiled, so the next 99 times through the 
loop execute only compiled code, allowing the perfor- 
mance of the system to be essentially the same as the per- 
formance of a traditional compiled system. 

Once the value of I reaches 101, the test in line 30 is 
true, causing the compiler to be invoked to compile line 
70, In this case, the code for line 70 cannot directly overlay 
the call to the compiler, because doing so would overlay 
code for other program lines. Instead^ the code of line 70 
is appended to the end of the rest of the compiled code 
and the call to the compiler for line 70 is replaced with a 
branch instruction to the code for line 70 (Fig, 4i). The 
program then terminates, but the compiled code is still 
present. If the user chooses to rerun the program, the RUN 
command now finds that the first line is already compiled 
and transfers control directly to it so that the second execu- 
tion of the program executes only compiled code. 



(g) Line 40 executed and iirie 50 compiled 



code tor line 10 

code for line 20 

code for line 30 
lest for I 100 
true: call compiler(70) 
falser code for line 40 

code for lirte 50 

call cQmpller(€0) 



(h) Lir>e 50 executed and line 60 compiled 



code for lir^e tO 
code for Hrve 20 
code for line 30 
test for I ■ 100 
true: call compllerfTO) 
false: code for Une 40 
code for fine 50 
branch 10 code for line 30 



(i) Line 30 executed {test was true) wid line 70 compiled 



code 

code for line 20 
code lor line 30 
test for r > 1O0 

true: branch to code for line 70 

fel$e: code for line 40 
code for line 50 
brancli to code for line 30 
code for fine 70 
end program 



Fig . 4- Exampfe of run- time aompiiing . See text for expiana tion , 



Interactive Features 

In traditional interpretive systems, special checks for 
user interactions or tracing take place at the beginning of 
each line. Checking one or more flags can be done with 
just a few machine instructions, which require a very small 
overhead compared to the overall execution of the interpre- 
ter. In a compiled environment even a few instructions can 
consume a large percentage of the total execution time of 
the program. The solution developed in cooperation with 
the CPU microcode team was the start-of- line- check in- 
struction SOLC. This instruction is the first instruction of 
every compiled BASIC line. It performs two important 
tasks. One. it checks a word at the base of the stack for 
zero versus nonzero. If one or more bits in the word have 
been set, indicating that something special needs to occur, 
a trap occurs and the system takes the appropriate action. 
If the word is zero, execution proceeds to the next instruc- 
tion* Second, the SOLC instruction writes its own address 
at a fixed location in the stack so that the system can always 
find out which line is being executed. 

A traditional interactive feature on Eff desktop comput- 
ers has been the live keyboard. The user can evaluate ex- 
pressions, examine and modify program variables, and exe- 
cute BASIC statements from the keyboard while the pro- 
gram is running. When a Model 520 user presses the EXE- 
CUTE key after typing in a command, one of the bits in the 
SOLC check word is set, causing a trap to occur at the next 
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SOLC instruction. The system then parses, compiles, and 
executes the interactive command before returning control 
to the program line that was interrupted. 

Another traditional HP interactive debugging feature is 
the ability to trace program flow by enabling the TRACE 
mode. This causes a message to be displayed on each nonse- 
quential transfer of control, showing the source and desti- 
nation line numbers. When a Model 520 programmer ena- 
bles tracing, another bit in the SOLC check word is set 
which causes a trap on every SOLC instruction. The system 
can then determine whether or not the BASIC line cur- 
rently being executed is immediately after the previously 
executed line* and display an appropriate message if it 
is not. 

Another important debugging capability is the ability to 
trace the assignments to program variables. When the pro- 
grammer enables variable tracing, the system, enters a mode 
where a trap occurs on every store into a memory location. 
The system can then determine if the location is the loca- 
tion of a program variable, and if so, display a message 
with the new value of the variable and the line number of 
the line that changed the variable. 

Although enabling either or both of the tracing modes 
slows down program execution speed significantly, the 
program usually executes faster than the programmer can 
follow it unless the trace messages are slowed down with 
the TRACE WAIT statement, which causes a delay after every 
trace message is displayed. 

The occurrence of an asynchronous ON condition also 
causes a bit to be set in the SOLC check word. When the 
next SOLC instruction executes, a trap occurs and the sys- 
tem sets up a branch to the specified service routine if the 
scope and priority conditions are satisfied. The system 
transfers control to a piece of static object code at the begin- 
ning of a context, which in turn branches to the service 
routine if it is already compiled, or to a bootstrap sequence 
to invoke the compiler if it is not yet compiled. CALL or 
GOSUB branches invoked by the ON condition return to the 
point of interruption as directed by the static object code 
after handling the ON condition. 

Program Modification and Continuation 

While debugging a program, a programmer often wants 
to be able to make a fix to the program and resume execution 
without having to start the program over. The run-time 
compiler allows the Model 520 Computer to support this 
capability with a compiled system. As an example, suppose 
the author of the program in Fig. 4a decided during the 
execution of the program to calculate the squares and 
square roots for all integers up to 1000 instead of 100 as 
in the original program. Suppose that the program was at 
line 40 when the programmer entered the editor and 
changed line 30 (Fig, 5a). The compiled code for the pro- 
gram is no longer valid, so it is thrown away. The system 
remembers that the program is currently at line 40. When 
the programmer continues the program, the system deter- 
mines that line 40 is not compiled and sets up a bootstrap 
sequence for line 40 similar to the way in which the pro- 
gram first began execution with hue 10 (Fig, 5b). Line 40 
is recompiled and executed, followed by line 50 and so 
forth (Figs. 5c to 5gj. The compiled code is rebuilt a line 



at a time, just as it was constructed the first time. 

There are some restrictions on what lines can be changed 
while a program is running. Lines that have only partially 
been executed cannot be modified or deleted. For example, 
a line that invokes a multiline function or a subprogram 
cannot be changed, or the function or subprogram would 
lose the place it should return to. The SUB statement that 
defines an active subprogram cannot be modified or deleted 
until that subprogram returns to its caller. A similar restric- 
tion holds for variable allocation statements such as DIM 
and COMMON statements in an active subprogram. These 
lines that cannot be changed are called busy lines. 

Even though a busy line cannot be changed, the compiled 
code for it may still be invalidated by an allowed change 
to the context containing the line. In the case of a iine that 
invoked a multiline function, it must be recompiled when 
the function returns. It is clearly undesirable to have to 
check on every return from a function or subprogram to 
see if the return point is still compiled. Instead, when com- 
piled code for a busy line is discarded, the return address 
in the execution stack is patched to point at an entry point 



(a) Example BASIC program 

10 PR^NT "Table of Squana and Square Roots" 

20 I = 1 

30 IF [ 100OTHEN Done 

40 PRINT l>|A2,SQH(IJ 

50 I - 1+1 

eO GOTO 3C 

70 D0n&:^MD 



(b) CONTINUE command bootstraps to resume execution 



{c) Une 40 compiled 



G<KJe for line 40 
<»ll compJIert&O) 



(d) Line 40 executed and line BQ recompiled 



code for line 4€ 
code tor line 50 
call compller(6Q) 



(e) Line SO executed and line 60 recompiled 



code for line 40 
code for line SO 
code for llne(30} 



(f) Line 30 recompiled 



code for line 5-0 
code for line 30 
test for I . 1000 

true: call compJlar(70^ 

false: branch to code for Ifne 40 



(g) Line 30 eiteciited (te^t was true] and line 70 compiled 



code for line 

code for line 50 ' 

code for line 30 
test for I 1000 
true: branch to code for line 70 
false: branch to code for Urm 40 

code for line 70 

end program 



Fig. 5. Effect of Interactive program modiff cation on run-time 
compilation process. See text for explanation. 
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Preserving Programming Investment 



An important consideration throughout the desfgn of BASIC 
tor the HP 9000 Model 520 Computer was upward compatibility 
with BASIC for the HP 9845 and HP 9000 Series 200 Computers 
Even though the Series 200 appeared more ihan a year before 
the Model 520, the !wo BASIC language systems were designed 
concurrently. A compatibility committee composed of members 
from botti design teams coordinated the two efforts. As a result, 
Model 520 BASIC m a nearly pure superset of Series 200 BASIC, 
Thus, almost any Series 200 program can run without modification 
on the Model 520. The most stgnificant change is usually for 
device select codes. The relaiionship between HP 9845 and 
Model 520 BASIC is more complex. Some features of the Ian- 
guage were redefined to improve the consistency of the language 
and to pave the way for future development. The most signifEcanl 
changes are in the I/O and graphics sublanguages. Since not 
all HP 9845 programs can run on a Mode! 520 Computer without 
modification, a translator program was written to assist users in 
porting valuable existing software to the Model 520. 

Experience to date with transporting HP 9635 and ^P 9845 
programs to the Model 520 has been quite good. Many programs 
execute successfully without modification, and most will execute 
correctly after manual modification of a few syntactically invalid 
lines. In spite of the success rate of porting programs without 
the translator, use of the translator program is recommended as 
insurance against some subtle semantic changes There is a 
small set of programs that do require great effort to port. These 
programs contain a signilicant number of device-dependent por- 
tions or portions written in assembly language. Included in the 
device- dependent set are programs that depend heavily on di- 
rectly addressing the CRT display and on certain uses of its 
video enhancement options. 

There are three basic difference categories that the translator 
program handles. First is where the Model 520 supports identical 
semantics, but by way of a different syntax. Second is where the 
Model 520 supports the same syntax, but assigns different 
semantics to it. Third is neither of the above. Elements of this 
last set range from a slight change in semantics, whtch may 
affect program behavior only very infrequently, to features that 
have no equivalent and require user understanding of the intent 
of the program to make the changes. The translator recognizes 
almost all of these, flags them, and gives suggestions on how 
to translate manually. 

The best example of first category is the modulo operator MOD, 
which has been changed to modulo in the Model 520. Some 
others can result in a single line expanding to multiple lines (see 
MATINPUT example below), but the semantics are stil I preserved . 

The most pervasive example of the second category Is the 
change from BCD to binary arithmetic, in this case the translator 
issues diagnostics when it sees potential probiems such as 
noninteger numbers in for loop bounds and step sizes, or rela- 
tional equality tests where exact equality was possible with BCD 
values, but will not be with binary values, A second example is 
the change in precedence for some operators. For example, the 
NOT operator has lower precedence on the Model 520 than on 
the HP 9835 and HP 9845 Computers. 

Translation Examples 

In many cases, the changed precedence does no! affect the 
results of computations. For example, the expression -axb 
means (-A)>:8on the HP 9835 and HP 9845, but it means -[A>B) 
on the Model 520. Either interpretation of the expression pro- 
duces the same answer (with the rare exception of an overflow 
\n an intermediate result). There are cases, though, where the 



changed precedence does matter The expression -3 mod 2 
yields a value of one on the HP 9835 and HP 9845 because it 
is t-3) MOD 2 The expression -3 modulo 2 yields a value of - 1 
on the Model 520, because it is interpreted - (3 MODULO 2). After 
passing through the translator, the HP 9835 and HP 9645 expres- 
sions appear as {-A)x B and | 3) MODULO 2 The -a is paren- 
thesized unnecessarily, because of simplifying assumptions in 
the expression parser. These simplifying assumptions are con- 
servative — they may cause unnecessary parenthesization, but 
will not omit any necessary parentheses. 

When the translator encounters the statement 

20 FOR 1 = 1 TO 2 STEP .1 

It gives the warning 

FOR loop witli non-integer bounds or step size may behave ditferently due 
to binary arithmetic. 

Most of the items handled by the translator could be done 
manually, though at the cost of considerable tediumi. For exam- 
ple, inputting an array can be done on the HP 9B45 by the 

statement 

100IVIATINPUTA 

The identical operation on a the Model 520 is accomplished by 

100 INPUT A(*) 

The \-\P 9845 also allows the redimensioning of an array by an 
INPUT statement, but the Model 520 does not. The statement 

100 MAT INPUT A{3,5) 

translates to 

too REDIIV1 A(3,5) 

101 INPUT A(') 

Finally, consider an extreme case where the HP 9845 statement 

100 IF X>3 THEN MAT INPUT A[ N DiV M. N MOD U) 

is converted automatically by the translator to 

100 IF X>3 THEN 

101 REDIM Mi-H) DIV M,[-N) MODULO M} 

102 INPUT A(*) 

103 END IF 

If adding new lines creates duplicate line numbers in the pro- 
gram source, the translator issues a diagnostic, and correction 
of the problem will require user intervention after getting the 
translated source. No attempt is made to renumber existing 
source lines, since that would also require finding and changing 
any programming references to the affected line numbers. 

One of the most complicated translation examples can be 
found m the cat statement. The HP 9845 statement 

100 CAT TO A$(*),Skip.N:"sel©ctof:msus",1 

translates to 

100 CAT ■:msuE'' TO A$(*); SELECT 'sefector'HSKlP Skip COUINTT N.MOHEADER 

Note that every parameter after AS(t) in the orrgmal statement is 
optional. Furthemiore. with the exception of the final portion (,i), 
each parameter is independent of all the others, and in the string 
selector msus, either the selector or the :msus portion could appear 
without the other, In all cases the associated parameter in the 
translation is lefl out or included as necessary. The final .1 is 
whai causes the NO header portion to appear in the translation. 
If this portion Is .0, the noheader portion does not appear. If the 
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final portion is a vanatile. a d^agnostfc is given to the usQf to 
check the statement for possit>!e manual changes. 

jfiipl9fTi8ntaiJQn 

The translator implementation draws much from conventional 
compiler techr>olOQy. It is driven by a recursive descent parser, 
which in turn relies on a scanner to t)uild language tokens by 
reading the input statement one character at a time. At first 
glance^ it appears thai the translator would require complete 
knowledge of the HP 9S35 and HP 9645 BASIC language gram- 
mar. Arithmetic expressions can occur in all sorts of strange 
places in BASIC statements, and every one of them must be 
inspected for possible changes 

The most significant simplifying assumption is that each input 
program is a syntactically valid HP 9645 program as SAVEd by 
the HP 9845's interpreter. Thus, many statements may be trans- 
lated with no knowledge of their grammar Each BASIC statement 
is treated as a sequence of expressions [usually delimited by a 
blank or a comma) which can generally be inspected and trans- 
lated independently This means that isolated keywords are pro- 
cessed as an expression by themselves. Complex expressions 
may cause recursive calls on the expression evaluatorto evaluate 
subexpressions such as parenthesized expressions, functjon or 
procedure parameters, etc. 

Of course, things are not quite that simple everywhere. Some 
statements must be understood in greater detail. They are han- 
dled in typical (nontabte-driven) recursive descent fashion. When 
a keyword or expression type is detected at any level that requires 
more detailed analysis^ a handling procedure is called, which 



may itself invoke the expression e valuator to handiG the subex- 
pressions To support this detection and subseqiient handling, 
the expression e valuator afways retums the type of the exp region 
It found and fis starting and ending character positions in the 
source statement This mformation must be kept until the state- 
ment ss completely processed, since some statements require 
tf>e rearrangement of many of their express tons Which translated 
expression goes where depends on the type and/of existence 
of certain other expressions in the original statement. This kind 
of support IS required for statements such as the CAT example 
earlier 

In all cases the translator tries to get by with the leas! under- 
standing necessary to translate 3 given statement Any phmary 
keyword that requires no sp^eciai handling is processed at the 
outermost level by calling the expression e valuator successively 
untfl the end of the statement is reached 

The translator itself is written in Model 520 BASIC It contains 
about 45O0 statements, and was designed, coded, and tested 
by one person in ten weeks. There were two key factors in this 
short development period First, all required translator actions 
were well defined in advance. That is, the probfem to be solved 
was clearly stated. Second, the Model 520 provided an excellent 
interactive deveiopmeni/debugging environment. 
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in the static object code for the context that will set up the 
compiler to recompile the busy line and resume execution 
at the appropriate place in it. 

Summary 

Model 520 BASIC has the interactive friendliness of pre- 
vious interpretive systems with the execution performance 
of a compiler. All of the interactive features of BASIC in 
HP's earher desktop systems are supported. 

The extra overhead Introduced by run-time compiling 
accounts for less than 5% of the execution time of most 
programs and it is less than 1% for many of them. The 
compiling that takes place at run time is very fast since 
syntax is checked as lines are entered and the intermediate 
code produced i.s optimized for compiling. 

For large programs, the intermediate code and object 
code are each about the same size as the source, (This does 
not include run-time support routines which are consid- 
ered part of fhe system,] Because of the ability to throw 
away code when no more memory is available, a program 
can run (sbwly) In just slightly more memory than is re- 
quired for the intermediate code and variables. Further- 
more* the system provides the ability to produce and exe- 
cute compiled code without any associated intermediate 
code by using the COMPILE command. 
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A Local Area Network for the HP 9000 
Series 500 Computers 

by John J, Balza, H. Michael Wenzel, and James L. WiMits 



HEWLETT-PACKARD'S Manufacturer's Productivity 
Network (MPN) divides the computing applications 
for a typical manufacturing company into four areas: 
accounting, manufacturing, factory control, and computer- 
aided design. Data is collected and stored in each area and 
access is provided to users via combinations of com^puting 
and neti^'^orking. Data access by users in the same area is 
required frequently and to other areas more intermittently. 

In the computer-aided design area, scientific and en- 
gineering workstations are connected into clusters for re- 
source and information sharing. LAN 9000 provides the 
capability to cluster HP 9000 Series 500 Computers on a 
local area network. In the future, additional HP-UX* work- 
stations such as the HP 9000 Series 200 Computers will 
also be connected to this local area network. 

Communication between the four MPN areas occurs over 
a backbone network. The backbone may consist of various 
forms of communication technology such as a local area 
net^vork, packet switching, and private branch exchange. 
LAN 9000 can also serve as a backbone network connecting 
HP computers from the other three MPN areas. 

Definition of LAN 9000 

LAN 9000 is a product composed of both hardware and 
software. Its structure follows the ISO [International Stan- 
dards Organization) OSI (open system interconnect) model, ^ 
which divides network functionality into seven layers [see 
Fig. 1). In the LAN 9000 implementation, the physical and 
link layers are accomplished in hardware, and the remain- 
ing upper layers are implemented in HP 9000 software. 
The physical layer provides access to the physical com- 
munications media. The link layer defines the frame format 

* HP-UX is MP's implementattDn ot the UNIX'* operating syst^n 
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and the protocol for error detection. The internet layer 
provides the protocol for connecting multiple networks, 
multiplexing, and data segmentation and reassembly. The 
transport layer provides end-to-end reliability » multiplex- 
ing and flow^ control. The session layer provides a common 
interface to the transport for the applications* The presen- 
tation and application layers provide data translation and 
the actual network services visible to the user. 
Hardware. The LAN 9D00 hardware implements the phys- 
ical and iinJt layers for the Ethernet local area network 
specification. ^^^ The hardware consists of an HP-IB (IEEE 
488) interface card connected to an Ethernet interface unit, 
which in turn is connected by twisted-pair branch cable 
to the transceiver that taps the 50-ohm Ethernet coax cable 
(see Fig. 2). Ethernet is a bus configuration where conten- 
tion between multiple stations is resolved by a technique 
called carrier-sense multiple-access and collision detect 
[CSMA/CD]. The transceiver provides the driver electronics 
for the cable, and the Ethernet interface unit provides ad- 
dress recognitionj arbitration, and error detection. The 
Ethernet specification supports lOM-bit/s performance for 
up to 100 nodes on a 500-meter segment of Ethernet coax. 
Each branch cabie can be up to 50 meters long. 
Software* The LAN 9000 software consists of the upper 
layers of protocol and a supporting network architecture 
(see Fig. 1). which will be discussed later The transport 
and internet levels were originally defined by the U.S. Defense 
Advanced Research Projects Administration (DARPA)^-^ 
and are currently used in a large functional network called 
ARPANET** The transport layer is called the transmission 
control protocol (TCP) and the internet layer is called the 
internet protocol (IP). The applications consist primarily 
of three functions: the ability to access remote files, the 

Tne LAN 9000 impiemervEatio" i5 a subset ot ihe DARPA prcjtoGots and has no! been 
tesled for use on AflPANET 
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ability to acbie\^e high-speed transfer of files, and a lower- 
level tool that enables users to initiate and communicate 
with remote processes progranmia!ically^ 

Accessing remote data is accomplished both by remote 
file access (RFA) and network file transfer (NFF). RFA is 
advantageous when accessing individual remote records 
and when using existing programs that access files. The 
method of access for RFA is a simple extension of the file 
path name with a remote specifier. For exam pi e^ the differ- 
ence in HP*UX commands bet\¥een editing a local file and 
a remote file on node george Is: 

Local: vl textfile 

Remote: vi /netgeorgetextfile 

NFT is advantageous when the high-speed movement of 
a file from one system to another is desired. After transfer, 
the new file can be accessed for processing. NFT achieves 
about four times the throughput of RFA by using large 
blocks and a pipelined transfer technique. The topology 
for NFT is the three-node model, where the initiator, pro- 
ducer, and consumer can all be on different nodes. NFT is 
accomplished with the dscopy command, which includes 
the source and destination file path names as parameters. 
File security is invoked for both RFA and NFT by the system 
containing the file. Security is applied to remote access 
consistent with the mechanisms used for local access. 

Interprocess communication (IPC) and remote process 
management [RPM) are lower-level tools that enable a user 
to write custom distributed applications. They consist of 
a number of procedures that can be called from the user 
program. RPM gives the program the ability to create and 
execute another program on a remote system and to termi- 
nate it. IPC consists of procedures to establish a communis 
cation path, read and write data, and terminate the path^ 
The communication patii is called a virtual circuil and 
enables full-duplex communication between both process- 
es. The rendezvous between the two processes is achieved 
through a name assignment by one process, a name lookup 
by the other process, and then a handshake to establish 
the virtual circuit. The IPC functionality was modeled after 
the IPC specified in the 4.2BSD version of UNIX^" de- 
veloped by the University of California at Berkeley (UCB)* 

Design of LAN 9000 

Early in the project we knew that there would be several 
major problems to be solved. It was our intention to select 
an architecture so that as our networking needs changed, 
the architecture would still support them, Several key prob- 
lems were recognised. First, we knew that we would be 

UMIX Is a U.S trademark of Bdl Laboratories 
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dealing with several operating systems as well as several 
processor families. At the time w^e w^ere considering at least 
two different operating systems and processors* one of 
which was the NMOS-lII VLSI 32-bit system used in the 
HP 9000 Series 500 Computers. We wanted to build soft- 
w^are that could be used in any multitasking operating sys- 
tem with any processor family. 

Second, we knew from experience that many protocols 
would need to be implemented within this architecture. 
While there are some industry standard protocols today, 
work in this area Is just begiiuiing. To meet HP customer 
needs in the future^ we would have to support a variety 
of protocols at each of the seven levels of the OSI modeh 
Even if we only implemented industrj^ or international 
standards, there would still be a multitude of protocols, 
because many different physical configurations could be 
used to construct a network. While our initial product was 
only for local area networks, eventually we would need 
remote connections and connections over public data 
networks. 

Third, the system had to be robust and integrated. There 
were several computer scientists working on the original 
product and over time many more would contribute to the 
networking functionality. We needed to define an environ- 
ment where these designers could work independently and 
stilJ have the result appear to be one integrated product 
that would be free of errors. 

Because of these challenges, our first task was to define 
what we eventually called our data communications im- 
plementation architecture. This architecture is a com- 
prehensive specification of module interfaces. As shown 
in Fig, 3. these modules are successively layered in their 
isolation from the host operating system. For efficiency 
and portability, the network protocol modules assume a 
very high-level execution environment that is tuned for 
networking code. Similaxly, the execution environment 

(continued on pagd 25) 
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Data Communications for a 32-Bit Computer Workstation 

by Vincent C, Jones 



The HP 9000 Series 500 Computers pface heavy demands on 
data communicaiions Aside from the locaf networkmg capability 
provided by I-j^N 9000, there arenumeroLfs other needs, because 
the real world does not consist exclusively of HP computers 
running HP networking software. The range of these needs is 
even wider than normal because of the pivotal nature of the 
Series 500 itself It needs not only the communications capability 
of a smgle- user workstation, but also those of a powerful multiuser 
machine. 

Single -user workstations, even those as powerful as the desk- 
lop version of the Series 500, the Model 520, do not function in 
isolatFon, Effective problem solving often requires synergy be- 
tween mainframe resources and the individual workstations. This 
requires easy communication between workstation and main- 
frame, particujariy interactive terminal-oriented access and reli- 
able file transfer. .A typical application might require the Model 
520 to offload some computation- intensive tasks from a main- 
frame, allowing the mainframe to provide better response to a 
larger number of users. 

In multiuser mode. Ihe emphasis tends to be more along the 
tine of resource sharing among the different users. The communi- 
catFon link with other mainframes is a resource to be shared the 
same as a line printer or data base The interactive linkup from 
the user's terminal to multiple mainframes is not as important a 
need as the ability to gel required data to the user's local main- 
frame for processing, to communicate with users on other main- 
frames, or 10 move programs and data to larger, more specialized 
mainframes for processing, 

A second dimension to the matrix of data communications 
needs is the network environment in which the mainframes oper- 
ate SIM A (systems network architecture) and bisync are common 
with IBM host computers while DecNet™ and UNIX'" predomi- 
nate on host computers made by Digital Equipment Corporation 
(DEC) HP's DSN services are simifarly tuned to take advantage 
of the strengths of HP computers, while Burroughs., Univac, and 
just about every other computer vendor offer their own networking 
solutions Unfortunately, they are all incompatible, making it 
necessary to implement a number of solutions while remaining 
hopelessly incomplete. However, IBM is such a dominant force 
m the mainframe market that virtually all vendors offer connection 
to IBM using emulation techniques. Indeed, IBM 2780,^60 RJE 
(remote pb entry) has become so prevalent among minicomputer 
vendors that it is considered a de facto communications standard 
for reliable file transfer even in non-IBM environments. Similarly, 
almost everyone allows effective on-line access from "dumb ' 
asynchronous ASCII terminals. 

This lets us deftne a minimal set of communications abilities 
to allow efficient use of the Series 5ID0 in most computing environ- 
ments Returning to the fundamental needs of users, we need 
interactive mainframe access and reliable file transfer. An asyn- 
chronous ASCIE terminal emutalion with programmable data rate, 
character size, parity, stop bits, end-of-line, start-of-line, prompt, 
and other parameters can be configured to access virtually any 
computer that can connect to ASCII terminals. By making the 
emulator user^modifiable (by providing source code or other 
techniques), access can be gained to any host that supports 
asynchronous terminals Adding the capability to divert host 
transmission to a file and use file input in place of keystrokes 

UNIX IB a U.S rrademark of Bell Lstwrdtories 

DecNei 4S a U.S. irsdenmrk oi Digital Equvprnem Cofparation 



provides a simple, low-cost file transfer capability Where higher 
data integrity is required. IBM 2780 RJE provides a synchronous, 
error-controlled linking. 

This teaves only interactive IBM access to provide, more com- 
monly known as 3270 capability. Asynchronous terminal emula- 
tion can be used with black boxes known as protocol converters, 
but typicaify these are useful only under limited conditions Most 
important, they are not a one-for-one replacement tor an IBM 
3270 display statfon, which requires users to memonze multi- 
stroke key sequences to access the myriad key functions avail- 
able on actual 3270 systems. However, where limited or occa- 
sionat access is required, especially if the user is also no longer 
using "the reaf thing," they can function quite well 

Unfortunately, IBM 3270 does not specify a unique access 
means. Instead, ii es an entire family of products including cluster 
CO nt rotters, display stations, printers and integrated controller/ 
display stattons For example, to meet vaned customer needs 
and keep up with technology advances, there are over twenty 
different models of 3274 controllers (some are obsolete) There 
are more than ten different models of 3278 and 3279 display 
stations, any of which can be used with current 3274 controllers. 
Despite the plethora of options, however, there are really only 
two approaches to 3270 emulation. The first {and until late 1982, 
the only approach) is to emulate the entire cluster controller and 
attached display stations using bisync or ENA protocols to con- 
nect to the mainframe via a 370x front end. Commonly called 
3274 emulation, this approach is particularly attractive for mul- 
tiuser Situations, where up to 32 users can simultaneously access 
the mainframe through the emulator while requiring only a single 
link from the local computer to the IBM mainframe, 

The second approach, pioneered on the IBM Personal Com- 
puter by Technical Analysis Corporation (now Digital Communi- 
cations Associates, Inc.). is to emulate only the display station, 
leaving the existing IBM cluster controller in place and hooking 
into the coax protocol used between controller and display sta- 
tions. Commonly called 3278 emuiation, this approach is most 
attractive when replacing individual display stations with com- 
puter workstations. Either approach, however, can typically be 
used in Ihe majohty of applications, albeit not always optimally. 
This means that the critical interconnection needs of most work- 
station users can be met with just three networking products: 
flexible asynchronous terminal emulation, stmple IBM 2780/3780 
remote job entry emulation, and some form of IBM 3270 capability. 

In addition to these minimal requirements, other communica- 
tion needs are common enough to demand specific resolution, 
particularly for efUcJent integration into HP, DEC, and UNIX envi- 
ronments as well as IBM. 

Impfementatlons 

There are probably as many ways to develop the required 
capabilities as there are opinions in what makes up an adequate 
set of capabilities. We had choices ranging from "offer what's 
already available off the shelf" to "design, devetop and build 
from scratch " As will be seen, we tned to select whatever would 
provide a quality product in the shortest time — typically taking 
an existing product and modifying it as required, 

The first communications products developed for the Series 
500 were two general-purpose asynchronous terminal emulators 
With file transfer capabilities — one for BASIC and one for HP-UX. 
Crucial to both was providing enough flexibility to communicate 
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wjtti Virtually any compiler that uses ASCII characters on an 
asynchfonous line. This mearFS not only supporting slandafd op- 
tions Hke line rates from 50 to 1 9,200 fets per second. 7-bit or 
8-bit chafacters. and vanous panties, but afso ai^owing options 
like defining what charactefs to use for now itne and xQHaOFF 
host prompts before transrriitting the next line, and Irne-Ofiented 
modes complete wnh start -oMirte and end-of-ttne sequences. 
Also required was ttm abifity to funcfion with existing proioeoi 
converters fof IBM 3270 and RJ€ 

The BASIC asynchronous temiinaS emutaior is based on the 
HP 9845 Computers htgh- speed terminal emuialor, mafntaining 
Mie same human interface so thai users movmg yp from the HP 
9845 would not have to le-am a new emulator The HP-UX asyn- 
chronous terminal emulator (tfefrn) is just the opposite, a new 
design from the bouom up. At the moment, the jmplementation 
is only part of the total design Several cfi^ical features allowing 
modular extensions and user customizalion cannot be im- 
plemenied until enhancements to HP-UX that will permii one 
process to rehably react to two concurrent asynchronoys inputs 
are in ptace 

Once we were confident our minimal needs were covered, we 
Goufd start locking at how to provide more specific connections 
Primary chteria were timeliness of the implementation and utility 
to the user This led to three mam communications thrusts: HP 
connection via Ethernet, IBM connection via RJE. and UNIX con- 
nection via CL (cali UNIX) and uucp (UNIX-to-UNfX copy). 

As mentioned earlier, IBM communications consist of two major 
capabilities: 3270 interactive access and remote job entry While 
efforts are underway to provide built-in 3270 capability, our initial 
eflort went into file transfer via RJE. At the beginning of the 
project, we had to select from a number of potential options For 
example, did we want to do just 2780/3780 RJE or did we want 
to take advantage of the multiuser capabilities of the HP 9000 
Series 500 Computers and provide muitileaving RJE (MRJE)? Bell 
Laboratones' System [II UNIX, which we were building on, had 
an MRJE capability (the send command) However, that capability 
was built using a virtual protocol machine running on the DEC 
KMC-11 communications card In addition, the System 111 pack- 
age was based on the assumption that the only use for RJE 
would be to submit pb streams to IBM and Untvac hosts, an 
unacceptable restriction in view of our desire to use RJE also to 
exchange files with minicomputers 

Our solution was to try to take the best of both approaches; 
keeping the convenient jOb submrttal facility of the System IF I 
MRJE user interface (the sefid command), but putting It atop a 
2790/3780 RJE program (r2780) which could also be used di- 
rectly by the user jf only file transfer were required Also required 
were two utility programs a trace filter to convert card trace data 
from the compressed binary fornr* generated on-line to a readable 
listing, and a print output filter to expand IBM carriage controls 
to HP-UX compatible sequences The HP-UX standard definition 
for send is link-independent so that although the current Series 
500 implementation is 2 780/3780 -I ink- based, future enhance- 
ments such as MRJE or SNA links to IBM could be added without 
affecting the user interface 

Third on our list of required connections, after HP and IBM^ is 



DEC Intef active access is fairiy easy on multiuser systems — the 
aierni asychronous terminal emulator can be made totally trans- 
pareit. allowing ttie user to rake advantage of the ANSI compati- 
bility nnode offered on several HP terminals The Model 520 work- 
station user IS restncted, however, to "dumb lermmal' only While 
we consider the resthction undesirable, we do not envision many 
users interested sn dedtcating a 32- bit workstation to terminal 
emulation for data entry and editing Similarly. A would be nice 
to hook into DecNet for file access and data transfef . but again 
prioriites have prevented immediate satsslactton For now. RJE 
suffices fof reliable file transfer, even ttiough it requires a second 
terminal connection to the DEC machine to control that end of 
the connection 

Last on our list of required connections is UNIX. Since HP-UX 
IS based on UNIX, we felt it v«tal that we fit into the UNIX data 
communications environment, To simplify retaining compatibility 
with evolving releases from both Bell Laboratories and the Univer- 
sity of California at Bert<eley, we attempted to take the standard 
System 111 UNlX4o-UNiX utilities and change them as littfe as 
possible We started out with txt, uucp and uu% (UNIX-to-UNIX 
execute). Although our goal was to leave them intact, we dis- 
covered significant design changes were required Most critical, 
other than fixing numerous bugs, was removing restrictions 
based on the Bell assumption that all users would have source 
code to modify Because HP-UX does not include an AT&T source 
license, features requiring modification of the source code are 
not acceptable unless that source code can be provided to the 
user by HP (i e,. was designed and written by HP, not Sell Labs). 
Since all these utifities are based on asynchronous dial-up linl<s, 
smart modems are normally used Unfortunately, each modem 
manufacturer seems to use a different protocol to tell its modem 
how to dial a specific phone number Our solution was to move 
dialing out of the main program and put it into a separate program 
module, which is called trom the main program and wrftten by 
the user (no source license required) Sample programs showing 
how to dial Ven Tel and Racal Vadic modems are supplied 
Similarly, in uux the list of programs that can be run from a remote 
machine was moved from a data array inside the program to an 
external file Visible changes from Ihe System 111 version were 
minimized. By retaining The ongtnal functionality and interface, 
standard UNIX utilities that use uucp still work as expected, includ- 
ing remote mall and the notes network. 

Ackno wJ edg ments 

Larry Bruns developed the BASIC asynchronous terminal 
emulator. Chhs Fugitl wrote the HP-UX asynchronous terminal 
emulator, and Don Rosen baum modified the UNIX communica- 
tion utilities, including moving modem dialing out of the main 
program into a separate module. 

Continuing our close working relationship with the I/O card 
developers at HP's dtvtsion in Roseville. California, Rick Dow 
developed the r2780 program at Fort Collins, Colorado, while 
Brian Krelle did the I/O card firmware at Roseville Along Wfth 
them, Larry Bruns did the trace and print formatting filters, and 
then brought up the System III send command. 



modules build on other environment modules and reiy on 
the services of the host system interface* which provides a 
machine-independent operating system interface. The host 
system interface code consists of small and partially port- 
able modules that (jerform whatever actions are necessary 
to adapt the host machine's operating system for network 
use. For the Series 50f) operating system, called SUN (see 



articles on pages 28, 34, and 38). many of the host system 
interface functions are null, that is, straight passthroughs 
to system intrinsics. Ultimately, the host system interface 
modules could grow to constitute a small operating system 
in themselves when less functimiality is provided by the 
host machine. Notice that only these modules call the host 
operating system directly rind, therefore, they contain the 
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only nonportable network code. 

Togetheit the execution environment and host system 
interface modules provide multitasking with process syn- 
chronization, memory management and accounting, inter- 
task message and queue management, nodal management 
{which controls and coordinates all the other modules in 
the network subsystem), uMlities for manipulating the 
shared-memory protocol interface data structures, and a 
library of miscellaneous utilities (like hashing routines*) 
which are of general use for protocol modules. 

Fig- 4 shows the logical organization of a protocol build- 
ing block. This block encapsulates the code for a given 
protocol. The main function of the network implementa- 
tion architecture is to define the interfaces betw^^een a pro- 
tocol building block and the blocks above it (which use its 
services), the blocks below it [on which it depends), and 
the execution environment. The upper and lower interfaces 
are represented by shared-memory data structures. The ac- 
tions that take place at each interface aje represented by 
specific message types. 

The lower interface for a protocol building block consists 
of one or more functional ports — usually one, A functional 
port can be visualized as a terminal strip of female electrical 
sockets. (The related OSI concept is called a service access 
point.) 

The upper interface to the protocol building block con- 
sists of an end point for each of the protocol's instances of 
communication with a remote machine. An endpoint can 
be visualized as a male plug that attaches to a specific 
fimctional port of a higher [the using) protocol. [The OSI 
endpoint term refers to the following concept: Each pro- 
tocol building block regards an endpoint just below it a 
the end of a data path "wire'* that will carry its data tr 
peer protocol module in a specific remote machine,) 

The protocol building blocks are "plugged" together by 
nodal management for each instance of communication 
with a remote machine as shown in Fig, 5. This chain of 
protocol building blocks is referred to as a data path and 
is represented as a linked list of endpoint data structures. 
Data paths can join or branch to represent multiplexing or 
alternate routing. Fig. B shows the data path that supports 
an instance of network file transfer (NFT). All data and 
control information related to moving a file between the 
local and remote machines is carried by interna! messages 
flowing along this data path. 

Note that in the current version of LAN 9000 there are 

'Floutmes used to organize Ea&le& for rapvd searching or iDok-up. 



several alternative buUding blocks at the services level. In 
the future, there will also be alternative modules at all the 
other levels as well. The protocol building block structure 
will allow nodal management to plug together any combi- 
nation of alternative modules that Is appropriate for reach- 
ing a particular remote machine. For example, the endpoint 
underneath the internet protocol could just as easily belong 
to the X,25 protocol* block, which would then be served 
by an endpoint belonging to the LAPB (link access protocol, 
balanced mode) I/O card. Also, the MFT protocol could be 
supported by an entirely different set of transport protocols. 
We have already used the nodal management capability to 
replace protocol building blocks by arranging data paths 
through alternative modules. During development, we used 
alternate data paths to infect special test modules at various 
points above or below the code being developed. 

The architecture described above solved three primary 
problems. It isolated us from the operating system and 
processor set by providing a series of common function 
calls which we could create in any operating system. It 
defined a series of interfaces between protocol modules so 
that we could mix and match many protocols. These inter- 
faces were based on proposals in the ANSI and ISO commit- 
tees. Pinally, these interfaces allowed various protocol de- 
signers to design with some degree of independence and 
still be sure that the system would be an integrated package. 

We were concerned at first that creating all these module 
interfaces would cause performance problems, but that was 
a price we were willing to pay for the flexibility tlie ar- 
chitecture would give us. In the end, we were pleasantly 
surprised to find that with just a minimum of tuning, our 
performance was as good as or better than many other 
similar systems on the market. The code modularity and 
the architecture increased the productivity of our design 
group with no loss of performance. 

Quality Assurance 

It has long been a policy at our facility that the engineer 
who designed and implemented a module is responsible 
for the quality of that module. Follow^ing this policy, the 
designers wrote the test plans for their individual modules. 
This included both black-box and w^hite-box testing, Here^ 
black-box testing is based on the user manual or external 
specification of the module. While-box testing is based on 
knowing how the module was designed and stressing it at 
its w^eak points. Designers were responsible for doing their 
own white-box testing, and many also did their own black- 
box testing. The exception was wdien the module was de- 
signed to be used by HP customers directly. At this points 
an independent tester was assigned to do the black-box 
testing to give us an independent opinion on the usefulness 
of the module* 

The test plans formed the basis for determining when 
w^e w^ere finished testing. They were also used for schedul- 
ing this phase of the project. One of the best indicators of 
when the quality of the product is high enough to ship to 
customers has been ''Did w'e complete the test plan?*' This 
is one reason the test plan is reviewed by the quality assur- 
ance department to ensure that it Is rigorous and complete. 

"The CClin sianctaicf miafface protocol for packet g witching nelwofKs This standard con- 
sists of Uiree prolocol layers that conform lo the lowef ihres leveis at the OSI model. 
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The other major indicator of quality is a measure of tha 
mean time \o failure. This time is the machine time spent 
stressing the code in new ways, plus a derated amount of 
machine time spent running old test programs, divided by 
the number of failures detected. 

Since completing the test plan osually takes some time, 
we used a completion estimate for scheduling this phase. 
Each designer estimated the hours necessary to design each 
of the tests in the test plan. We then calculated the amount 
of time necessary Id find and fix code and design errors 
from our bistoricai data. Finally, we allotted time for over- 
head and unanticipated activities, .^er completing these 
estimates for each designer, we estimated that the test phase 
would take about 1 5 weeks. Since the test plan was actually 
completed in 16 weeks* we feit our estimate was quite 
good. But at this point we still had not met our goal for 
mean time to failure. 

In the course of doing testing, we came upon a new test 
method that we called triggers. Triggers is a method of 
triggering asynchronous events to occur at particular times. 
For example, if e routine asks for blocks of memory three 
times in its execution, we can trigger the system to reject 
the memory request at any of those three times. The trigger 
mechanism allowed us to test most of the paths in our 
code. It was this trigger mechanism that kept our measured 
failure rate so high in the beginning. Even though most of 
the events detected by the triggers were very improbable 
in real life, we continued to test for them until the triggers 
could not produce any more errors. Then we felt that we 
had a very solid system and we finally met our mean time 



to failure goal. This additional test time look another four 
weeks, but we felt the added code quality was worth the 
effort. Most of the problems \ve solved with this technique 
would have been very difficult to find and correct once 
the product was in a customer's hands. 

Future Directions 

The current version of LAN 9000 establishes the base to 
^ow into additional topologies. The evolution will be in 
the directions of connectivity to more kinds of workstations 
and systems, additional links and gateways, and inclusion 
of more industry standard protocols. The architecture pro- 
vides the flexibility to add protocols, and it facilitates the 
porting of the network software to other systems. 
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A General-Purpose Operating System 
Kernel for a 32-Bit Computer System 

by Dennis D. Georg, Benjamin D. Osecky, and Stepiian D. Scheid 



THE OPERATING SYSTEM KERNEL for the HP 9000 
Series 500 Computers efficiently supports the real- 
time requirements of the extended BASIC language 
environment as well as the multiuser requirements of 
HP-UX. The kernel provides efficient support for multiple 
processors, a process model that supports a large user pro- 
cess virtual address space, a virtual memory system that 
supports both paged and segmented virtual memory, mem- 
ory and buffer m^anagement, and a device-independent file 
system which has the capability of supporting multiple 
directory formats* The main objective of this operating sys- 
tem kernel, called SUN, is to provide a clean interface 
between the underlying hardware and the application -lev el 
systems such as BASIC or HP-UX. 

The SUN operating system can be separated into two 
sets of major components, as follovt^sr 



I/O 

Input/Output Switch 
Device Driver Modu les 
Input/Output Primitives 



Non-i/0 

Process Manager 

Memory Manager 

Buffer Manager 

Message Manager 

Timer Manager 

Trap Manager 

Dispatcher 

Nonvolatile Memory Manager 

System Startup Manager 



The I/O components of SUN are described on page 38. 

The SUN operating system manages the allocation and 
deallocation of hardware resources. Memory and proces- 
sors are the primary system resources. Other resources in- 
clude buffers, message queues, file directories, input/out- 
put charmels. processors, and timers* The management of 
these resources supports: 

■ The establishment of contexts (sets of code and data 
addresses) for the execution of sequences of instructions 

■ The allocation of the processor to the execution of spe- 
cific sequences of instructions 

■ The dynamic allocation of resources required by the al- 
gorithms being executed. 

Hardware and Operating Environment 

The Series 500 hardware provides a stack-oriented envi- 
ronment for program execution.^ Segmentation and paging 
are used to facilitate memory management. A simplified 
diagram of the operating environment is shown in Fig. 1 
on page 35. 

There are two basic types of segments: code segments 
and data segments. Code execution on a Series 500 CPU is 
contained in one or more code segments and uses several 



data segments. One data segment is used as an execution 
stack segment and at least one other data segment is used 
as a global data segment. Each CPU contains hardware 
registers to define and bound the current code, stack, and 
global data segments. Other segments, called external data 
segments, can be accessed indirectly through pointers 
stored in the stack and global data segments. External data 
segments can be paged. 

Information to manage the segments is kept in tables — 
one system segment table and many user segment tables. 
However, only one user segment table can be active on a 
CPU at a given time. The system segment table and the 
currently active user segment table define the address range 
of the program running on a CPU at any time. 

A device reference table contains an entry for each I/O 
channel. This entry contains information to establish the 
code segment and global data segment for I he interrupt 
service routine when the corresponding I/O device requests 
service. Each CPU has an interrupt control stack which 
serves as the execution stack for interrupt service routines 
and for the system dispatcher. 

The CPU hardware defines a task control block to de- 
scribe the state of a task. This block contains a pointer to 
the user segment table for the task and to the task's stack 
and global data segments. The CPU microcode uses four 
words of memory for each CPU in the system. These CPU- 
dedicated locations point to the current user segment table, 
the currently executing task control block, and the interrupt 
control stack for the CPU. 

Conte]d5 

For tills discussion, a context is a set of related addresses 
that define a scope of addressability, that is, limit the set 
of code and/or data addresses that are accessible. The SUN 
operating system supports program, process, and partition 
contexts. 

Program Context, The simplest context is a program, a set 
of one or more procedures. Each procedure is a collection 
of instructions, with a common entry name, which may or 
may not be parameterized. Instructions that make up a 
program are stored in code segments. A program may oc- 
cupy one OF more code segments or several programs may 
reside in one code segment. The address range (context) 
of a program is the set of code segments that it occupies. 

During program execution, procedure parameters and 
local variables and an execution stack are stored in a special 
data segment called the stack segment. Program variables 
that are not local to program procedures or parameters to 
those procedures can be stored in either the global data 
segment or in arbitrary additional data segments called 
external data segments. Externa! data segments are only 
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allocated as a result of explicit requests and can be either 
paged oT unpaged. 

The context of an executing program or process aJso in- 
cludes the current values of the hardware registers* which 
define the current state of the hardware and the relative 
state of the process. The hardware state of a process can 
be established using mfDrmation from the process' task 
control block and stack segment. 

While a program has a static context, a process is an 
active element with a dynamic context. In SUN, a process 
is defined to be a unique instance of a consecutively execut- 
ing program, and more than one process can share a pro- 
gram. The primary operational characteristic of a process 
is that the progress of any process in the system, as il 
executes its code body, is not guaranteed relative to the 
progress of other processes in the system. 
Process Context. The minimum context for a process con- 
sists of the program context, stack and global data segments, 
and the current hardware state. Each process has its own 
stack segment. Process contexts can be expanded by the 
addition of an arbitrary number of external data segments- 
They also can be dynamically varied by allowing the 
executing program to switch global data segments dynam- 
ically, create and delete external data segments, or extend 
or contract existing segments. 

Partition Context. A partition is a set of processes that 
share a common user segment table. This segment table 
has entries for the code and data segments that are local 
to the partition. Since the segment table entries contain 
the base address locations of the allocated segments as well 
as their current lengths^ the segment table defines the seg- 
ments the partition can address. 

Other than the availability of memory and segment table 
space, there is no limit to the number of processes that can 
exist simultaneously in a partition. All processes within a 
partition can share the same global data segment. This seg- 
ment represents the primary mechanism for sharing data 
among a set of processes within a partition. 

User partition contexts are created as a result of calls to 
the START_ PARTITION procedure. The procedure parameters 
specify the information required to construct a partition 
context as well as the context of the inital process that is 
to be created and executed within the created partition 
context. The execution of start PARTmON allocates the 
initial physical memory for Iht^ partition, initializes the 
segment table for the partition, allocates the global data 
segment for the partition, and establishes the context for 
the initial process in the created [jarlition. The initial pro- 
cess can request additional resources, or create additional 
process contexts. Like any other process in the system, the 
progress of the execution of the initial process in the created 
partition depends on its priority relative to other processes 
and the number of other processes in the system as a whole, 

A partition is deleted w^hen the last process in that par- 
tition terminates. The resources that make up the partition 
are then returned to the appropriate pools of available re- 
sources. 

System Partition Context* The system partition is a special 
context defirietl by the system segment table. Segments 
described by the system segment table are addressable at 
ail times. The union of the segments in the system segment 



table and the current user segment table defines the context 
of the machine at any time- The system segment table con- 
tains the system global data segment and other segments 
that can be shared by all processes in all partitions because 
of their global addressability. 

Every process context is allocated from within a partition 
context. There are two classes of processes: user partition 
processes and system processes. The main distinction be- 
tween user and system processes is the addressability of 
the stack for the process. The stack segments of system 
processes are allocated from the system segment table and 
are therefore always addressable. A system process can 
establish addressability to any partition context by chang- 
ing its current user segment table, which together with the 
system segment table, defines the current address space. 
User processes cannot address any segments described in 
any user segment table other than their own. 

Process contexts can be deleted explicitly or implicitly. 
A call to the SUN procedure PTERMINATE causes explicit 
termination of the current process. Implicit deletion occurs 
when the program being executed completes execution and 
exits its initial procedure. Regardless of whether the dele- 
tion occurs explicitly or implicitly, the effect is the same. 
The resources used to construct the process context are 
returned to the system for reallocation. 

Processes in the subsystems supported by SUN always 
execute within the context of a partition. Process contexts 
established in a partition context can be used to control 
asynchronous events or devices* simplify the solution to 
an otherwise more complex problem, provide execution 
environments that have special characleri.stics such as 
specialized trap handling procedures, or separate the 
execution of subsystem-supplied code from that of code 
developed by a user. 

An example of a process set provided by a language 
subsystem is tlie model developed by the BASIC language 
sutjsystem for the HP 9000 Model 520 Computer, an inte- 
grated desktop workstation. Each BASIC partition has ac- 
cess to a system human interface process and separate run 
and executive processes. The human interface process 
manages access to devices such as the Model bZQ's 
keyboard and CRT, which are controlled asynchronously 
by the user interacting with the machine. The executive 
process controls the state of the partition's run process, the 
parsing of language and command statements, and the com- 
munications with the human interface process. The run 
process performs the run-time compilation and execution 
of BASIC programs written by a user. 

Resource Ailocatton and Addressability 

In most cases J memory object resources are allocated 
from the partition containing the process making the re- 
quest. For example, a request for the allocation of a data 
segment by a process within a user partition context results 
in the allocation of the segment from that partition's seg- 
ment table. However, processes executing within user con- 
texts also have an ability to allocate/deallocate memory 
object resources from the system context explicitly. Pro- 
cesses executing within the context of one user partition 
cannot directly allocate/deallocate resources within another 
user partition context. 
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Parallel Development of Hardware and Software 



One ot the earliest goals of the Model 520 Computer (the 

desktop version of the IHP 9000 Series 500) project was to bring 
the completed system to ilie marketplace as soon as possibie 
after completion of ihe hardware The traditional project pattern 
in which development of the software lakes place after the com- 
pletion of the hardware was therefore inappropriate. 

To increase both the productivity of the software deveJopmeni 
team and the resultant quality of the final system software, a 
high-level language was designed to be used for all systems 
programming. This language, called MODCAL, is based on Pas- 
cal, but includes enhancements to allow separate compilation 
and to provide controlled access to certain architectural features 
of the HP 9000 Sehes 500 Computers so that the temptation to 
code in assembly language is greatly reduced. Since the lan- 
guage was used to implement the most fundamental parts of the 
SUN operating system, it was designed in such a way as to be 
suppol-free No supporting libraries and operating system are 
inherently assumed to exist by the compiler. The match between 
the language and ihe underlying architecture is further improved 
by the addition of a good compiler code optimizer, resulting in 
even less temptation to resort to assembly language. 

With this strategy it was possibie to develop most of the soft- 
ware modules which make up the system. At the end of the 
project more I ha n 96% of the system software had been coded 
in MODCAL. This percentage included ihe results of extensive 
tuning efforts in which modules found to be critical to the perfor- 
mance of the machine were receded in Series 500 assembly 
language. This overall stategy not only improved the productivity 
of the development team, but also resulted in a product with 
much better soft\ware reliability and maintainability. 

Although it was possible to test higher -level modules by execut- 
ing them on another system with simulated lower-level routines, 
it became apparent that the only acceptable way to check out 
lower-level, architecturally dependent software was to run the 
code in an environment that fully duplicated the characteristics 
of the final system, This requirement was especially critical for 
testing I/O driver code, Not only did it require the duplication of 
the CPU and I/O processor functions, but also the semantics of 
an I/O device. 

To allow all parts of the system to complete testing and inte- 
gration before the availability of functioning hardware, a detailed 
software emulator of the Model 520 was built. This emulator in- 
cludes detailed modeling of all parts of the CPU,'' memory con- 
troller,^ and most significantly, the I/O processor^ and backplane. 

The HP 9845 Computer, configured with an assembly language 
development ROM, was selected as the engine for the emulator. 
The friendliness of the assembly language development environ- 
ment allowed high productivity during the emulator development, 
The memory system of the HP 9S45 was sufficiently large (500K 
bytes) and the overall system cost was low enough to allow 
several systems to be purchased for the emulation function. The 
tast consideration was of extreme importance since the operation 
of the emulator is by necessity very computation-intensive and 
one or two copies of the emulator executing on a timesharing 
system would have completely consumed the system's proces- 
sor. Furthermore, the HP 3845 was aiso used as a MODCAL 
development station, alfowing a complete development station 
to exist on an engineer's desk. 

The emulator was implemented in stages. The functionality of 
the CPU registers and a sufficient fraction of the instruction set 
to allow the lowest levels of the operating system to be coded 
and tested were provided first This allowed most of the operating 



system kernel to be tested sufficiently to ready it for integration 
with partially tested higher-level software, Work on the emulator 
than continued to implement the instruction set more completely 
by including floating-point instructions and all instructions emitted 
by the MODCAL compiler. Most of the BASIC software system 
could be tested with ihe exception of the I/O drivers, file system, 
and human interface. A temporary I/O interface was added which 
allowed simple read and print I/O to take place to the keyboard 
and display of the HP 9845, 

Next, the complete I/O processor and I/O backpiane emula- 
tions were added. This consisted of software to model the state 
of the I./0 processor connected to an external device which pro- 
vided the hardware simulation of the new I/O backplane of the 
Model 520, Simulation of I/O device semantics could then be 
provided by actual I/O devices. This approach worked well for 
devices that were available for use, but a number of I/O devices 
ware still under development, A capability was added that al- 
lowed software simulation of these unavailable devices. 

Coda was added to the emu later to capture dynamic measu res 
of instruction and memory access mode use. The execution 
monitor function supported by these additions allowed the soft- 
ware development team to evaluate coding alternatives and to 
begin tuning the system before hardware was available. The 
functionality of the emulator was tested during its development 
by a battery of architectural verification tests which were de- 
veloped in parallel with the emulator. These tests not only served 
as a cross check on the correctness of the emulator, but they 
were also used as vehfication tests for the NMOS-ltl chips when 
preliminary versions became available. 

The finished emulator allowed complete integration of all com- 
ponents of the Model 520's BASIC system, including the human 
interface and I/O drivers. The execution rate of the software was 
1000 times slower than real time, but was sufficient to allow 
BASIC statements to be stored at the rate of one every 20 sec- 
onds. At this point some of the software modules were sufficiently 
stable to allow the start of quality assurance testing. 

Finally the hardware was ready. The 35 OK- byte BASIC operat- 
ing system was loaded into the prototype and the system was 
functional. The parallel development strategy was successful. 

Acknowledgments 

The parallel development strategy was made possible be- 
cause of the efforts of Marcel Meier and Bruce Rodean who 
constructed the battery of architectural verification tests and 
helped debug Ihe I/O system, Eric Nelson and Craig Robinson 
who provided the HP-9845-bus-to-HP-9000-bus adapter, Jeff 
Eastman, Roger fson. Scott Wang, Karl Jensen, Mike McCarthy, 
Tim Tillson, Tom Lane. Mike Connor, and ethers who provided 
the MODCAL development environment, and Bill Eads and Mike 
Kotesar who provided a supportive management environment. 

References 

1 K P Surkhart e1 s'r "An le-MHz. 32.BI1 VLSI Micropiocessgr,' Hewl^tt-P^ckgn^ 
Joornai, Vol. 34, no B, August ISSB 

2 C G Lob, et al, "Hlgh-Perfomnance VLSt Mefriofy S/stem," fbid. 

3 F J Gross, W,S JaMe, and D.?\ Wsiss, "VLSt \J0 ProcBSsOf fot a 32'Bit Comput^f 
System. " ibfd. 

-Bertjarrtin D. Osecky 
-Dennis D. Georg 



30 HEWLETT^ PACKARD J0URP4AL MARCH 198*i 



)Copr. 1949-1998 Hewlett-Packard Co. 



Other types of obiects can be allocated by calls to the 
operating system. Buffers are contiguous sections of mem- 
ory that are guaranteed never to be relocated and can there- 
fore be referenced by using absolute addresses. Buffers are 
mainly used by the 1/0 part of SUN as temporary holders 
of data being transferred either to or from an I/O device. 

A message link is a queue receptacle to which messages 
can be sent and from which messages can be received. 
Message links are allocated by SUN from a segment that 
exijrts in the context of the system partition. 

Resources allocated from the system partition have global 
addressability since all partitions see Ihe system address 
space as part of their address space. Resources allocated 
in partitions other than the system partition cannot be ad- 
dressed from other user partitions. The ability to address 
user partitions is provided to system processes via the pro- 
cedure CHANG E_TO_ PARTITION, which establishes user ac- 
cess to the specified partition. 

Virtual Memory 

The operating system provides support for virtual mem- 
ory used in HP-UX in the form of both segmentation and 
paging. Virtual segments are treated as indivisible entities 
of variable length that can be swapped to a storage device 
when not in use. Virtual objects can also be allocated in 
paged external data segments which are divided into equal 
pieces called pages. Each page can reside in physical mem- 
ory independent of the other pages that make up the object. 
Virtual segmented objects can be up to 500K b\1:es in size* 
while virtual paged objects can be up to 500M bytes. 

The hardware provides indicators for each virtual object, 
allowing the operating system to determine if the object is 
currently in physical memory, and if it is, to determine 
whether the object has been referenced and/or modified. 
The operating system uses this information in its replace- 
ment algorithms to choose segments or pages to be removed 
from physical memory when necessary. 

The operating system supports the sharing of virtual ob- 
jects among several processes. It also supports the mapping 
of files into virtual objects, thus providing access to a mapped 
file at memory speeds. Virtual objects can also be locked 
in physical memory to prevent relocation during 1/0 trans- 
fers to or from the object. 

Communications 

SUN and the language and applications subsystems sup- 
ported by it are sets of communicating processes. The initial 
process within the user context is free to develop an arbi- 
trary set of processes. No structure is imposed on the pro- 
cess set within user partition contexts. However, all pro- 
cesses within a partition context share a global data seg- 
ment and other segments that they can commonly address. 

The simplest form of communication occurs at proce.ss 
creation when a single-segment relative pointer is passed 
as a parameter to the program to be executed in the new 
process context. This pointer can have no value or can 
point to an arbitrary parameter structure. This level of com- 
munication is similar to the parameter passing that occurs 
when one procedure calls another procedure within the 
same process context. 

Processes executing within the same partition context 



can share data in the global data segment or other external 
data segments defined in their common segment table. All 
processes can share data in segments defined in the system 
segment table. Pointers to shared data or the shared data 
itself are stored in global data segments that are common 
to the communicating processes. 

In addition to supporting commtini cation via inter* 
process parameter passing and shared data in global data 
segments, SUN supports communication via message pass- 
ing. This support is provided by the message manager com- 
ponent. The message manager supports interprocess global 
communication by allowing one process to construct a 
packet of information called a message, send that message 
to a mailbox, and have a different process at an later time 
receive the message from the same mailbox. Processes com- 
municating via messages can exist eitlier in the same or 
different partition contexts. All that is required to initiate 
the communication is knowledge of a common message 
mailbox name, which SUN refers to as a message linL 

Synchronization and Scheduling 

Semaphores and semaphore operations are used to syn- 
chronize and coordinate processes. A semaphore is im- 
plemented as a tw^o-word data structure that can be allo- 
cated anywhere that can be commonly addressed by the 
synchronizing processes. There is no limit on the number 
of semaphores that can exist in the system. They are used 
to protect and provide exclusive access to shared data and 
to block a process until signaled by another process. 

The semaphore operations are designed to be safe in a 
multiple-processor environment. By safe, it is meant that 
the operations on semaphore data objects are guaranteed 
to be indivisible and complete regardless of the number of 
processors in the system. A more complete description of 
the operation of the process synchronization primitives 
can be found in the article on page 34. 

SUN also provides procedures for synchronizing pro- 
cesses with time. These procedures allow processes to wait 
for a specified time interval or to wait until a specified 
absolute time. Absolute times and intervals are specified 
as floating-point numbers in units of microseconds. 

At any time, all processes can be divided into two groups: 
runable and blocked. In addition, a subset of the runable 
processes is actually executing on the CPUs of the system. 
In a system with n CFUs* up to n processes can be executing 
at the same time. Processes become blocked by explicitly 
dovming a semaphore, attempting to receive a message 
that has not yet arrived, or waiting on a timer. 

The SUN operating system supports sets of subsystems 
that, in general, have more processes to be run than proces- 
sors. The dispatcher provided by the operating system is 
responsible for selecting runable processes to be executed 
by the CPUs based on process priority. Entry to the dis- 
patcher occurs whenever a dispatch instruct ion [DISP] has 
been executed and the current state of the system allows 
the dispatcher to be entered. The DISP instruction is exe- 
cuted by process synchronization and manipulation primi- 
tives when the state of a process is modified. In particular, 
the dispatcher is entered whenever a currently executing 
process is blocked, when a process that is of higher priority 
than a currently running process is made runable, or when 
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A System Software Debugger 



For the VLSf chip set used in the HP 9000 Series 500 CompuU 
ers, Iwo avaitabte levefs of debugging evolved, The iow-levei 
capability uses a separate HP 9B45 running a huge BASIC pro- 
gram, atlached to another electronic tool, which in turn connects 
to the NMOS-III CPU or I/O processor debug ports. The high-level 
debugger is a large software package thai is linked with an 
operating system It uses debugging support toofs built into the 
microcode to help programmers debug that system. 

Major Features 

Ttie debugger supports stepprng, breaking, and profiling at 
the procedure, statement, and machine ins I ruction levets. 
examines and changes memory and I/O in a variety of ways, 
disassembles machine instructions, dumps process status, pro- 
cedure chains, CPU registers, stacks, and variables, executes 
procedures, prints hard-copy audit trails, and passes control to 
user-defjned debugging software 

The debugger is menu-dnven. Most command prompts are 
less than one line long. Each command is a single letter that is 
accepted as soon as it is typed. Given the speed of the underlying 
hardware, this makes for a responsive, naturat-feeling human 
interface which combines the best of both menu and command 
line styles. Novices hnd the debugger easy to use (or quick, 
simple interactions Experienced users lend to learn short com- 
mand sequences that accomplish common operations. 

The menus range in Jength from short (two options) to quite 
long (Iwelve options at the top level). Most functions are only two 
or three levels deep, and every menu bu! the top one can be 
exited by typing O (options), 

Most menu lines are cleared after the user responds, which 
keeps the visual clutter to a minimum. When multiple-character 
input is required, the debugger requests it between menus in 



as compact a form as possibie. 

The first four options— Pstep, Siep. Focus, and Resume— on the 
lop levef resume the current process, eilher stepping at the pro- 
cedure, statement, or machine insl ruction levels, or resuming 
execution with no change of debug state. The Break option sup- 
ports maintenance of procedure, source statement, machine in- 
struction, memory location, and external process breakpoints. 
Machine instruction breakpoints can be local (one process only) 
or global (alJ processes) Clear sets the slate of the debugger to 
free-run. 

The Exam option leads to a powerful memory and f/0 access 
capability. For examining memory, it first allows the user to specify 
the initial memory location \n one of a number of ways, either as 
an absolute address, relative to various data registers and seg- 
ments, or by variable name or program location- Then it supports 
forward and backward stepping through and jumping around 
memory, going indirectly through data and absolute pointers 
{with a return stack), modifying locations, and viewing arbitrary 
byte sequences Meanwhile, the Exam lo option supports simple 
I/O requests and status displays. 

The Dump option capabilities include task status, accumulated 
CPU use by processes, procedure calling chains, CPU registers, 
and stack and variable dumps The &Xec option allows users lo 
call any procedure in memory, with a specified parameter list, 
under debugger control The Toggle option controls debugger 
modes, including partial and full hard-copy audit trail printing. 
The Meas Option interacts with iha optional procedure, source 
statement, and machine instruction execution and coverage 
monitor (profiler). 

Finally, the twelfth option, Ud, leads to a user-defined debugger, 
if one Is present Software authors can easily write iheir own 
extensions and plug them in at link time. 



the priority of a currently running process is changed. This 
ensures that the hi ghost -priority process in the set of run- 
abJe processes is selected for execution. 

The dispatcher completes the state-saving operation in- 
itiated by the DISP instruction, selects the highest-priority 
runable process, marks the selected process as runnings 
restores a subset of the hardware registers based on values 
stored in the task control block associated with the selected 
process, and executes an interrupt exit (IXIT) instruction. 
The IXIT instruction causes the remainder of the hardware 
state to be restored and process execution to resume. 

Interrupt Handling 

The normal flow of the execution of the machine instruc- 
tions can be modified by three mechanisms: external inter- 
rupts, internal interrupts, and traps. External interrupts 
signal requests for service by 1/0 devices. Internal inter- 
rupts signal abnormal conditions within the system that 
are not associated with the execution of a machine instruc- 
tion. Traps differ hom interrupts in that traps result from 
conditions detected by the hardware during the execution 
of an instruction. The detailed handling of interrupts and 
traps is done by the operating system. 

The hardware defines 16 priority levels that can be as- 
signed to each I/O cfianneL The interrupt structure is such 
that a higher-priority device preempts a iower-priority de- 



vice. Furthermore p a special hardware register, called the 
mask register, can be used for the purpose of masking off 
specific priority levels. The initial handling of external 
interrupts is done by the CPU microcode interrupt handler. 
The interrupt handler is executed on behalf of a particular 
device when all of the following conditions are met: 1) the 
device has requested an interrupt, 2] interrupts at the de- 
vice's priority level are not masked, 3) the interrupt bit in 
the status register Is enabled, and 4) no higher-priority 
device is requesting service. 

The interrupt handler initially saves the state of the 
machme by pushing a stack marker onto the stack segment 
for the currently executing process. The stack marker con- 
tains the information necessary to restore the status of the 
interrupted process, and hence allow execution to resume 
later. The information includes the index register value, 
the address of the first instruction to be executed when the 
machine status is restored, the machine status indication 
register, and a pointer to the previous stack marker. 

External interrupts are handled on a special stack seg- 
ment called the interrupt control stack. In this case, the 
CPU registers are modified to point to different stack and 
global data segments before the execution of the interrupt 
service routine. Before this register modification, the values 
of the registers associated with the interrupted process are 
saved in the process" task control block and stack segment 
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The debugger contairrs a complete uset 1/0 facility for 
keyboard input and display and opticmal hard-copy output Like 
nnost parts of the debugger, this code *s as independent as 
possible of any particular operating sysienn implementatkjn 

Most of the debugger I/O and mode- control routines (about 
34 in all) are exported to the fest of the system software. Thts m 
especsaJfy invaluable lor d^xjgging system 1/0 software and for 
supporting miscellaneous test harnesses. 

The debugger includes two optional packages which can be 
included at fink lime It the disassembler is present, afJ displays 
Of code are disassembled while examining, dumping, or step- 
ping. If the execution monitor (profiler) is present, the Meas option 
comes alfve. adding a numt^er of features 

The debugger is part symbolic. Compiie-time options permit 
each procedure to be followed by a short symbol table, Including 
a procedure name and possibly variable names and locations, 
tf thts information is present, the debugger uses it wherever it 
can, Debugging of "nondebuggabte ' procedures is still possible. 
but procedure and variable information is entered and displayed 
strictly by numeric address. 

Implementation 

This debugger is Intraprocess, not interprocess. Rather than 
occupying one or more dedicated debugging processes that 
interact with others, the debugger is inactive until Invoked. If the 
debugger is present, every process has a small amount of space 
{about 240 bytes) set astde at the base of its slack for permanent 
debugger variables The debugger uses aimost no other data 
storage. 

When activated, thedebuggerrunsontop of whatever process 
Invokes rt To ensure a stable environment, it turns off interrupts, 
takes exclusive control of the machine {pausing all other CPUs), 
and Is careful not to relinquish that control until exited. 



The operatir^g systems supply a limited number of special 
support mutir\es to heip the debugger gather information about 
and control other processes and operating system data stnjc- 
tures. Tnese routines help insutate the operattng &ystem4 and 
debugger from each other, max^mizirig mdependertce. 

The Vt_SI chip microcode provides a handy set of debugger 
support featyfes There are a number of spectal assembly instaic- 
dorrs whtch. when enabled, cause software traps that lead to the 
debugger (if present). These instructions are planted in debug- 
gable code by the compiler and enabled by the debugger on a 
process-local basis as needed for simpte, efTictent procedure 
and source statement stepping Since the status register does 
the enabling/disabling, the debugger state becomes a pari of 
the process state The CPU microcode also supports machine 
instruction stepping and a single absolute-address break regis- 
ter. both of which operate through the trap mechanism 

The debugger Is linked with one of a number of low-level I/O 
driver modules, each of whfch provides the same exported pro- 
cedure names These modules allow the debugger to run on an 
emulator, or on real hardware with the Model 520's keyboard 
and its various display options, or via an ASl or multiplexer card 
connected to a dedicated temiinaJ. 
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so that they can be restored before the process resumes. 

The interrupt handler writes the device number of the 
device requesting service onto the interrupt control stack 
at a known location. The device number serves as an index 
into the device reference table, which contains an entry 
for each I/O channel. The device reference table entry for 
a requesting [/O device is chained by an 1/0 processor onto 
a queue corresponding to the priority of the device to await 
service by a CPU. Each device reference table entry contains 
a pointer to the interrupt service routine, and a pointer to 
the data relevant to that I/O channel. 

The SUN operating system contains a single main inter- 
rupt service routine. Device driver procedures are executed 
by system and user processes as a result of input/output 
requests. When a device driver procedure wants to wait 
for an interrupt , the procedure calls a special operating 
system primitive which executes e DOWN operation on a 
semaphore associated with the device, thereby blocking 
the executing process. The interrupt service routine does 
an UP operation on a semaphore associated with the device 
driver procedure that handles interrupts for the interrupt- 
ing device J and thus unblocks the process which had been 
waiting for the interrupt. The interrupt service routine exe- 
cutes an IXIT instruction which may force the execution of 
the dispatcher if the freed process is of higher priority than 
the currently executing process. If the unblocked process 
is not dispatched, then the state of the interrupted process 
is restored and its execution continues. 



The hardware detects 45 different traps, or exception 
conditions. These traps are catagorixed into seven classes 
by the operating system to make exception handling more 
manageable. The seven classes are system, address, pro- 
gram, instruction, stack overflow, trace, and debug traps. 
System traps include absent segment and absent page traps, 
and other traps that support virtual memory. 

The trap manager component enables traps other than 
system traps to be handled by the higher-level subsystems 
in a hierarchical manner. Trap handling routines can be 
specified that apply to a specific process^ to atl processes 
in a given partition, or to all processes in the system. Trap 
handlers installed at the process level have the option of 
either handling the exception and returning to the inter- 
rupted process or referring the trap to the partition level. 
Similarly, partition level trap handlers can optionally refer 
handling to the system level. 

Protection 

The subsystems supported by the SUN operating system 
benefit from the protection of system integrity supported 
by the hardware as well as the protection provided by SUN 
itself- The protection provided by the hardware falls Into 
three categories: segment bounds checking, mode checking, 
and segment attribute checking. 

All segment (data or code) references are checked by the 
hardware to ensure that the references are within the 
bounds of the segment. Furthermore, any attempt to write 
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to a segment is checked to ensure that the segment is writ- 
able. All segments also have an attribute that indicates if 
the segment can he accessed hy code that is designated as 
unprivileged. This prevents user processes from directly 
executing code that is strictly for internal system use. Any 
violations are detected by the hardware and cause traps. 

The operating system provides protection beyond that 
provided by the hardware hy providing an independent 
partition segment table for each user partition context. Seg- 
ment accesses within a partition are limited to segments 
within the system segment table and to segments within 
the segment table local to the partition. In addition, SUN 



provides addressability checks at critical points in the 
execution of its procedures. 
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The Design of a General-Purpose Multiple- 
Processor System 

by Benjamin D, Osecky, Dennis D. Georg, and Robert J. Bury 



ALTHOUGH A NUMBER of earher liewlett^ Packard 
products have contained multiple-processor config- 
urations, none has been able lo bring the full power 
and flexibility of these processors to bear in solving user 
problems. For instance, the HP 9845B Computer contains 
an identical pair of 16-hit processors with shared memory. 
However, the system architecture constrains one processor 
to handle the computational parts of a user's program while 
the other processor, vi^hich accesses only the I/O bus, man- 
ages the iiiputyoutput and other operating system hmctions. 
Although this partitioning of functions provides a perfor- 
mance advantage over a single processor for applications 
in which the requirements for I/O and computation are 
relatively balanced, the configuration does little to improve 
the performance of strictly computational or mostly I/O- 
oriented workloads. 

Many other multiple-processor systems exhibit forms of 
asymmetry between their computation and iopot/ootput 
functions which are a result of eilher their hardware or 
their software architecture. On some systems a particular 
I/O device can be accessed by only a subset of the proces- 
sors. Communication with such a device requires either 
complex communication protocols betwreen the asymmet- 
ric processors or constrained execution of the user program 
on the processor subset. Other multiple-processor systems 
allow only a single processor at a time to execute operating 
system code. 

Hardware Design 

Tiie hardware architecture of the HP 9000 Series 500 
Computers has been designed to provide for a fully symmet- 
ric multiple-processor architecture. All CPUs. I/O proces- 
sors, and memory controllers are interconnected by the 
memory processor bus. All I/O processors and memory are 



identically addressable by all CPUs. This implies that a 
program can execute on any of the system's processors 
without any changes to the way the system addresses either 
memory or 1/0 devices. Perhaps equally important is the 
fact that all I/O processors have an equally symmetric view 
of CPUs and memory. This makes it possible for a program 
to initiate an I/O operation on one processor, for the inter- 
rupt service routine to execute on the same or a different 
processor, Eind for the user program to continue on a third 
processor, all with complete transparency. 

This symmetry is also exploited to improve system relia- 
bility. When the system is turned on, the processor compo- 
nents perform a self-test and report their results to one of 
the processors which is temporarily designated as a master. 
This master CPU begins the execution of operating system 
code that determines the number of system, components 
that have passed I heir self-tests and configures the system 
based on these working components. Once the system has 
been configured. Hie distinction of the master CPU is can- 
celed and the system begins normal operalioot except for a 
possible loss of capacity caused by any failed components. 

For a multiple-processor system to be able to deliver a 
significant performance improvement over a single proces- 
sor, each processor in the system must be provided with 
sufficient bandwidth to the system memory. In the HP 9000 
Series 500 Computers, the memory processor bus provides 
a bandwidth of 36M bj-tes per second. The memor\^ con- 
trollers are fully pipelined and are capable of responding 
to arbitrary reference strings al this maximum bandwidth. 
Measurements of the bandwidth consumed by a single 
Series 500 processor indicate that the average consumption 
is approximately 9M bytes/s. 

Another important hardware characteristic is a test-and- 
set operator that is atomic (indivisible) with respect to mul- 
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Fig . 1 . Process state as seen by 
the Series 500 hardware. 



tiple'processor execution. This operator is provided by the 
memory controller to allow the execution of a special re- 
quest that indi visibly reads and sets a selected word in 
main memory to a predetermined value. This operator 
serves as a building block for constructing mare complex 
synchronization operators in software. This hardware 
operator is also used by the CPUs when accessing certain 
table structures known to the hardware, such as page tables. 
This allow^s synchronization of access among processors, 
and between processors and the operating system software. 
called SUN, when the table entries must be modified. 

Another important characteristic is the ability to share 
the same image of an executing program between two or 
more processors. This is done by providing an architecture 
in which all code is reentrant. Code ts protected from mod- 
ification by the hardware. This allows a single image of 
the operating system to be shared by alt processors in the 
system and also allows several processors to be active in 
the operating system code simultaneously. 

Finally, since the SUN operating system was designed 
at the same time as the hardware, it was possible to make 
many hardware/software tradeoffs to improve the perfor- 
mance of SUN. The processor instruction set provides con- 
siderable assistance by saving and restoring process states 
during process switching. Fig. 1 illustrates the process state 
known by the hardware. The task control block ts selected 
by a processor register. Information contained in this block 
identifies a process' address space, stack segment and 
gifjbal data segment through either system or user segment 
table entries. The process stack contains information at its 
base that allows setting the stack limits and the current 
frame pointer. Absorbing the topmost stack frame allows 
information about the process* code segment and register 
state to be established. This entire procedure is accom- 
plished by the IXIT instruction. This instruction and the 



complementary state-saving operations combine to provide 
fast process context switching times* 

Software Design 

Each process in the system has its own task control block 
and stack segment. The information contained in the task 
control block includes process state information which is 
knowm to the hardware as well as an extended process 
state maintained by the system software. The state informa- 
tion known to the hardware includes the specification of 
the user's address space, stack, and global data segment as 
described above^ The software state includes the process 
priority, its dispatching state, fields to allow the process 
to be queued on a semaphore, a specification of action to 
be taken in the event of an exception condition, and a list 
of objects owned by the process. 

The process priority indicates the relative priority of 
execution of n on blocked processes- The highest' priority 
process not blocked on a semaphore is always allocated a 
processor. If a lower-priority process is running and a 
higher-priority process becomes ready because of some 
event such as the completion of an I/O operation, the lower- 
priority process is suspended and the higher-priority pro- 
cess is given a processor. This mode of scheduling in which 
a higher-priority process can preempt a lower-priority pro- 
cess is referred to as preemptive scheduling. The system 
software was designed to be preemptable in all but a few 
small code sections. 

The dispatching state indicates whether a process is wait- 
ing on a semaphore or a timer, ready for execution, or 
already running on a processor The address space indi- 
cates which virtual address space contains the memory 
objects local to the process. System processes often coexist 
within the same address space and communicate directly 
using shared-memory techniques. User processes for both 
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HP-UX and BASIC sj^slems each exist within their own 
address space, which can be up to 512 megabytes. Every 
process also has access to the system address space, which 
can also be as large as 512 megabytes. 

Three different mechanisms are provided to allow the 
synchronization of process activities: locks, semaphores 
and message passing. A lock provides the short-term ex- 
clusion mechanism normally provided by disabling inter- 
rupts while in a critical section on a single-processor sys- 
tem. This same effect is accomplished on a multiple-proces- 
sor system by performing a special code sequence on a 
memory word, referred to as a lock word, that is associated 
with the critical section in qnostion. The exclusion opera- 
tion is performed by executing the instruction read and set 
to -1 and testing the result. If the result is not equal to 
minus one, the lock has been obtained and the critical 
section can be executed. If the lock value is already minus 
one, the processor must retry the indivisible read and set to 
-1 instrnction until a nonnegative value is read- It is then 
assured that no other processor is active in the critical 
section. When the processor has reached the end of the 
critical section, it stores a zero back into the lock word to 
indicate that the critical section can now be entered by 
another processor. This locking mechanism is used many 
places in the system where exclusion is required for a code 
sequence that is short and does not execute any operations 
that cause the process to be blocked. 

A more general process synchronization tool is provided 
by semaphore operations. The implementation of sema- 
phores is similar to that proposed by DijLstra.^ A semaphore 
is a two-word area in memory that contains a value and a 
pointer to a linked list of processes. Semaphores can be 
allocated in memory anywhere that other data structures 
can be allocated, and there is no limit on the number of 
semaphores. Two operators are provided for semaphores: 
DOWN and UP. A DOWN operator applied to a semaphore 
with a value greater than xero merely decrements the value 
associated with the semaphore. If the value is less than or 
equal to zero, the value is still decremented, but the process' 
state is marked blocked and the process" task control block 
is added to the queue of w^aiting processes associated with 
the semaphore in order of priority. The UP operator incre- 
ments the value of the semaphore. If the initial value of 
the semaphore is less than r.ero and an up operation occurs, 
the first process waiting on the queue is marked as ready. 
If the process marked ready is of higher priority than the 
process executing the UP operator, tlie processor is given 
to the higher-priority process. 

Serialization can be provided for a critical section by 
associating with it a semaphore initialized to a value of 
one and providing a DOWN operator at the beginning of the 
critical section followed by an UP operator at the end of 
the critical section. Synchronization with a server process 
is usually accomplished with a semaphore initialized to a 
value of zero. 

The w^ord used as the head of the queue of tasks blocked 
on a semaphore also serves as a lock w^ord to guarantee 
proper operation of the semaphore in a multiple-processor 
system. Since there is a separate lock word for every 
semaphore in the system, the probability of contention for 
the lock is very low. 



During development of the software, it was found that 
considerable simplification would result by including ad- 
ditional semaphore operators. The first consisted of a con- 
ditional UP operator which would free all processes waiting 
on a given semaphore and allow the passing of an error 
escape code, This operator is especially usefnl in recover- 
ing from an error condition detected by another process. 
The second consisted of an indivisible DOWN and UP 
operator which would allow* a process to block itself on a 
semaphore while releasing another semaphore in one indi- 
visible operation. 

Message passing supports interprocess global communi- 
cations by allowing a process to construct a packet of infor- 
mation called a message, send that message to a mailbox, 
and have a different process at a later time receive the 
message from the same mailbox. Message passing and mail- 
boxes are used by both BASIC and HP-UX system processes 
to coordinate user processes. Sending and receiving mes- 
sages provides process synchronization similar to the 
semaphore UP and DOWN operations, coupled with an ad- 
dress-space- independent data transferrai. The message 
passing operations, in fact, are implemented using the 
semaphore operators, which in turn use the locking concept 
at the lowest level. 
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NUMBER OF CPU'S 



Rg. 3. Muitiple-processcf perfor- 
mance with a homogeneous toad. 
Each benchmark run consists of 
multiple identfcal copies of the 
same program 



Granuianty^ 

The duration of a typical process lifetime in HP-UX, 
which can last from a few tens of milliseconds to forever, 
is well matched to the granularity of the underlying process 
model The BASIC system's process model similarly is of 
reasonably large granularity. The times for representative 
operations for the underlying process model are: 



Operation 

Process Creation 

Lock Type Synchronization 

Semaphore Operation 

Process Switch 

Assign Free Processor 



Time (^s) 

1000 
5 
35 

150 
100 



To illustrate how the overall process model is im- 
plemented, consider the flowchart of the dispatcher shown 
in Fig, 2. When a DOWN synchronisation operation dictates 
a process b!ock> the process is marked blocked and the 
special instruction OISP is executed. This causes the pro- 
cess state to be saved and control to be transferred to the 
beginning of the short-term scheduler routine at the dis- 
patcher entr>' point. Upon entry, the dispatcher ensures 
that just one processor at a time is active within the critical 
section of the dispatcher by attempting to lock a word 

'In \hi& article, granularity is a measu^ oi the site €f independent DperaikmB l^lat a 
pfOC«ss or a progrojn can be broken up into for parallel proces^tng In each case, the 
performartqe bfenefnis gained by parallel processing musi be weighed againsr the syslen^ 
ove/head required to break yp Itie process or the program. Thai is. i\r\& gr&nui&nly requires 
rnor^ overhead 
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Fig, 4, Performance of bench- 
mark runs containing nonidentica! 
process loads. 
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associated with that critical section. Once inside the critical 
section, the dispatcher scans the United list of available 
processes using a special hardware linked-list search in- 
struction. The highest- priority process that is not blocked 
and is not currently running on another processor is 
selected for execution. The dispatcher's lock word is re- 
leased and the process is launched by setting the the CPU's 
current task control block pointer to point at the selected 
process. The context switch is completed by executing an 
IXIT instruction as described earlier. This results in the 
restoration of the state of this task and its continued execu- 
tion until it is either blocked or is preempted. 

If no tasks are found that are available for execution, the 
dispatcher's lock is released and the special instruction 
SLEP is executed. SLEP places the processor in a state where 
it is paused until the next interrupt or interprocessor mes- 
sage. In this way processors that have no work to do con- 
sume no bus bandwidth, yet are prepared to respond 
quickly when an event indicating the possible presence of 
a new runable task occurs. 

Performance 

The final test of the design of any multiple-processor 
system is in how much improvement in performance is 
provided by each additional processor. Fig. 3 shows the 
results of a number of benchmark runs which were made 
by running four copies of an identical benchmark on each 
of four processor configurations. The programs were 
selected to show the performance extremes that can be 
encountered in a multiple- processor system load. The pro- 
grams showing the least improvement were STRING 16K 
and STRING 80B. These programs make use of the proces- 
sor's block-move instructions, which are capable of moving 



data from one place in memory to another at the rate of 
9M bytes/s. Large and repeated block moves place a heavy 
load on the memory processor bus. 

The two-dimensional graphics benchmark is mostly 1/0- 
bou nd on a single processor and adding additional proces- 
sors does not produce a very dramatic result. The other 
benchmarks, 3D GRAPHICS. OsfTEGER, PCAL, and FLOAT- 
ING, are respectively a three-dimensional graphics program 
with I/O, an integer matrix multiply program ^ a very heavily 
recursive program^ and a floating-point matrix multiply 
program. All of these loads are significantly improved by 
having additional processors in the system. 

Fig. 4 shows the results of tests in which groups of 
uonidentical processes were run on systems containing a 
varying number of processors. The results from these runs 
are more uniformly clustered near the theoretical n-im- 
p ro v em en t -for- n- processors asjmiptote. This indicates that 
a significant Improvement is possible even for loads includ- 
ing bandwidth-intensive programs such as STRING 16K as 
long as they are included with programs containing more 
typical instruction mixes. 
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An I/O Subsystem for a 32-Bit Computer 
Operating System 

by Robert M* Lenk, Charles E. Mear, Jr, and Marcel E. Meier 



MEETING THE DIVERSE NEEDS for input/output 
processing for hoth the BASIC and HP-UX suhsys- 
tems in the HP 9000 Series 500 Computers posed 
a significant challenge during the design of the operating 
system called SUN. The BASIC language system for the 
Model 520 Computer provides a rich I/O language with 
support for real-time device and instrument control. HP-UX 
is a multiuser system which relies very heavily oo rapid 
access to disc storage for loading user programs, storing 
user data, and managing virtual memory. In addition, both 
systems provide users with a unified, device-independent 



I/O interface to all peripheral devices and mass storage 
files. SUN's I/O subsystem provides common code that 
fully supports the needs of both- 

The SUN VO sy.stem consists of two primar}^ software 
components— the file system and the device drivers. The 
device drivers provide a uniform high-performance inter- 
face for managing peripherals while the file system pro- 
vides file management, disc memory management, and de- 
vice management services to other components of the 
operating system as well as to user environments such as 
HP-UX and BASIC. In general, the structure of the I/O sub- 
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system {Fig. 1 ) mirrors the functionality of tke hardware* 

File System 

The basic unit of disc storage managed by the fiJe system 
is called a volume. Each volume has a slave process that 
performs all the I/O to the volume. The creation of a sepa- 
rate, transparent process allows physical I/O to be per- 
formed concurrently with other tasks and provides a 
mechanism whereby 1/0 requests can be scheduled in the 
most efficrent manner possible. Volumes have self-con- 
tained data structures upon which files and directories are 
implemerited. Directories, which map filenames into files, 
are managed solely by the file system while the interpreta- 
tion of the contents of files is left to higher-level software. 
Multiple Disc Formats. The file system supports file man- 
agement of three different disc formats: HP's Logical Inter- 
change Format [LIF], the disc format used by the HP 9825. 
HP 9835. and HP 9845 family of computers, and the Struc- 
tured Directory Format (SDF). The support for multiple 
disc formats was motivated by the desire to provide file 
interchange capability with other HP systems, to access 
discs initialized on earlier HP computers (backward com- 
patibility), and to provide additional capability not sup- 
ported by either the LIF or HP 9845 formats. The support 
for multiple disc formats does not introduce additional 
overhead to the file system. 

A distinct softw^-^re module mfmages each of the three 
formats. A common interface hides the disc format differ- 
ences from other file system software and the BASIC sub- 
system. When a disc is first accessed, the file system iden- 
tifies the disc by the contents of block on the disc and 
installs the correct software module to manage its structure* 
The file system returns an error if the caller attempts to 
use a feature not supported by the particular disc format, 
but otherwise no distinction between formats can be made 
by the application, Because of its extended capability, HP- 
UX supports only SDF' as its root file system. However, 
HP-UX applications can access LIP discs through standard 
utility programs* 

SDF supports capabilities beyond those of the other two 
disc formats. Among them are extensible files, hierarchical 
file naming, file links, extensible directories, mounted vol- 
umes, device files, remote file access support, and HP-UX 
file protection mechanisms. 

Each file on an SDF volume is described by a 128-byte 
file conuol block (FCB), similar to the UNIX'" inode. The 
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FCB contains inlorination about where the file resides on 
the disc, when it was last created, accessed, and modified, 
and how its use should be restricted. Disc space is allocated 
to the file in contiguous areas called extents (identified by 
the address of the first block of the disc area and its size]. 
This form of representation enables large, high-speed trans- 
fers between the disc and the memory, supports large files 
efficiently, and allows the amount of disc space allocated 
to the file to change dynamically. 

To support the needs of both the BASIC and the HP-UX 
systems, a portion of the FCB is reserved for private use 
by the subsystem that created the file. HP-UX. for example, 
uses this private data area to implement device files and 
HP-UX-style file protection semantics. 
Caching for Improved Performance. The file system uses 
a pool of equal -size buffers (buffer cache) to improve disc 
access performance. When data is read from the disc, it is 
placed and kept in the buffer cache. When a subsequent 
request is made for the same data, it can be retrieved from 
the cache without requiring any physical I/O operation. 
Accessing data in the cache is more than an order of mag- 
nitude faster than obtaining the same data from the disc. 

The number of buffers in the cache is determined when 
the system is initialized. Eventually the contents of one or 
more buffers has to be discarded to read new data from the 
disc (data not found in the cache). In this event* the cache 
buffer that has been least recently accessed is chosen, 

The cache is also used to improve performance in other 
ways. When sequential access to a file is detected, the file 
system prereads data from the file in anticipation of the 
next read request. The data is then kept in the cache until 
it is needed. The I/O required for the read is performed 
concurrently with the running of the application program. 
By prereading data, the file system overlaps CPU processing 
with I/O device time, thereby reducing the total time it 
takes to run an application. 

A large portion of the time needed to move data to and 
from the disc is spent waiting for the disc to prepare for 
the transfer. The actual transfer of data takes much less 
time. The file system transfers as much data as possible on 
each disc read/write. When prereading data, several buffers 
of data are read from the disc with one transfer. The cache 
also allows a file's dirty buffers (buffers that must be written 
back to the disc because their contents have been modified) 
to be gathered together and written to the disc in a single 
transfer. 
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Virtual Memory Support. Since many HP-UX systems are 
configured with only one disc, the file system must handle 
file management and virtual memory support together on 
a single volume. Each disc format module has entry points 
that the virtual memory system uses to allocate and deallo- 
cate disc blocks. These same high-speed disc space manage- 
ment routines are used by the file system to allocate disc 
space for directories and files. Disc storage is fully shared 
between the file system and the virtual memory system. 
The physical f/0 generated by the virtual memory system 
as a result of paging and segment swapping does not move 
through the cache, because the virtual memory system does 
its own caching through sophisticated page and segment 
replacement algorithms. This 1/0 is sent direGtly to a vol- 
ume's 1/0 process. The file system and virtual memory 
system together support the concept of a memory-mapped 
file. Files can be mapped onto a virtual segment and ac- 
cessed through a pointer. Once mapped, the virtual seg- 
ment contains an image of the file. Changes to the address 
space represent changes to the file and vice versa. This 
form of access is sometimes more convenient than standard 
file access routines and can, in certain applications, result 
in improved file access performance- 
Transparent Device i/0. Transparent device 1/0 for HP-UX 
is supported through device files, which contain informa- 
tion about the location of a device (possibly logical) in the 
system, and the manner in which the device and system 
must communicate. These special files are opened and ac- 
cessed in the same manner as other files. Their I/O. how- 
ever, is directed to the appropriate device- 
Drivers 

The underlying philosophy behind the driver architec- 
ture is that each piece of hardware is encapsulated by a 
separate module. A typical 1/0 operation in%^olves three 
separate pieces of tiardware: an 1/0 processor, an interface 
card, and a peripheral device.* Thus, the driver implemen- 
tation includes modules in three layers — I/O primitives, 
first-level drivers, and second -level drivers. This allows 
drivers to be mixed and matched for appropriate tasks with- 
out duplicating functions. Thus, all peripherals, whether 
discs, tape drives, line printers, or voltmeters, can share 
the same HP4B [IEEE 488) interface card first-level driver, 
while a single CS-80 protocol second-level driver can suf- 
fice both for HP-IB-based discs and the internal discs on 
the Series 500 's integrated workstation, the Model 520 [see 
Fig. 2]. Because of this modularity, the potential also exists 
to move any first-level driver to other machines where the 
same interface cards are present on different I/O channels, 
or to move any second-level driver to other machines where 
the same peripherals use different interface cards. 

Each of the three layers invokes the one below it through 
a procedure call This keeps the overhead of the modulari- 
sation to a minimum. However, in special cases where 
even this overhead is considered excessive, an individual 
driver module crosses these conceptual layers to optimize 
performance, A primary example of such an optimiieation 
is a special driver to do fast reads and writes of GvS-80 discs 
on the HP -IB interface. 

The modular driver organization allows softw^are to be 
configured to match precisely the hardware on which it 



runs. A minimal software system contains only the I/O 
primitives and the drivers necessary for a minimal 
hardware configuration without wasting kernel code space 
on unnecessary modules. As more hardw^are is added ^ the 
corresponding drivers are added to the software. All global 
system tables of drivers and devices are built dynamically 
by the modules that are present at system boot, rather than 
being compiled into a central part of the code or requiring 
a complicated system generation activity. Hence, the addi- 
tion of drivers does not require any recom pi lat ion or relink- 
ing of the system; it is accomplished by simply merging 
the driver code into the system boot area in HP-UX and 
rebooting, or by executing the LOAD BIN command in BASIC, 
The same ability to configure modules into the system is 
used by the file system for the modules that manage differ- 
ent disc formats, and by other subsystems outside of I/O- 
I/O Primitives. The primary' purpose of the I/O primitives 
module is to encapsulate the interface to the I/O processor 
and the services it provides. 7'hese services include direcl 
memory access [DMAJ transfers across the backplane, pass- 
ing interrupts to the CPU, and running channel programs 
[lists of I/O operations which are run by the 1/0 processor 
w^ithout CPU intervention). These services are presented 
to the drivers as routines that are independent of the nature 
of the I/O processor, such as setting up a DMA transfer or 
waiting for the interrupt at its completion, A few of these 
routines that are simple bot frequently executed are im- 
plemented with special compiler support by in-iine expan- 
sion in the calling driver's code. 

There are other tasks which, though not directly related 
to the I/O processor, are common to several drivers » and 
thus are also included at the priiuitives layer. For example, 
the primitives module examines all I/O slots at system in- 
itialization to determine which interfaces are present, This 
is an essential part of the self-configuration process, be- 
cause it allows each first-level driver to select which in- 
terface cards are appropriate for it to address wilhoot 
any knowledge of the behavior of other cards that may 
be present. 

The primitives also provide for resource allocation 
am^ong drivers to prevent multiple requests from interfering 
vrith one another. This is generally handled by providing 
mutual exclusion to each I/O slot, but it also involves the 
length of request. For shorter requests, interfaces such as 
terminal multiplexers allow multiple outstanding requests 
with certain restrictions, which are enforced by the primi- 
tives. For longer requests, each I/O processor has 
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bandwidth limitations, and in rare instances it is possible 
for a high-speed device to lock out a synchronous device 
on a separate slot. The primitives provide mutual exclusion 
between such incompatible devices on the same 1/0 proces- 
sor. 

HP-CIO. The HP 9000 Series 500 Computers are the first 
HP products to support HP's new family of interface cards, 
known as HP Channel I/O (HP-CIO). Each card in this family 
shares several levels of protocol, some of which communi' 
cate fairly complex tasks between the host computer and 
a microprocessor on the card. The card's microprocessor 
can perform such tasks as searching input streams for a 
termination character, or editing lines of text input from a 
terminal. Much of this protocol is encapsulated at the 
primitives level, allowing not only a sharing of code among 
drivers, but also efficient implementation of the protocol 
by matching it carefully to the I/O processor's functionality. 

The I/O primitives level provides a useful layer to insu- 
late the drivers from the 1/0 processor. Hence, all the inter- 
face card and peripheral drivers can be written in MODCAL 
(HP's internal Pascal-like systems programming language) 
rather than being forced to use assembly language. This 
encapsulation of the assembly language in the I/O primi- 
tives reduces the time required to design, code, test, and 
maintain the driver compared to programming in assembly 
language. The reliablity of the drivers is greatly improved, 
because it is easier to understand the code and its function 
when the code is in a high-level language. 
First- Level and Second- Level Drivers. The first -level and 
second-level drivers are designed to hide the anomalies of 
the peripherals and interface cards while providing all the 
functions that each device provides (e.g., full access to the 
instrumentation features of the HP-IB interface). 
Nonspecific device features are relegated to higher levels 
of the I/O hierarchy to prevent duplication of functions 
that would increase the overall size of the 1/0 subsystem, 
reduce performance, or possibly present inconsistent be- 
havior for different drivers. In addition to encapsulating 
the specific peripheral or interface card characteristics to 
provide access to a generic device, the driver design pro- 
vides access to rather dissimilar devices (e.g., discs and 
HP-IB interface cards) with the same parameters for either 
the first- or second-level driver procedures. This uniformity 
provides the first step in supplying the user with a totally 
device-independent 1/0 interface. 

The SUN operating system drivers also provide ex- 
tremely resilient recovery from error conditions. They have 
been through a thorough set of tests to ensure that the 
drivers never leave the device they control or leave the 
system In a bad state (requiring a power cycling of the 
computer or device) as a result of any possible error condi- 
tion. Extra effort was taken to provide a broad resolution 
of error conditions reported to the system rather than com- 
bining many different errors into generic error values. The 
drivers also provide numerous different soft-error reports 
to inform the user of nonerror related data such as the 
occurrence of an automatic data record sparing (replace- 
ment of a bad record with a good record) on a mass storage 
medium or a case where the system had to retry an access 
to a data record to obtain it without an error. This additional 
resolution and the soft-error concept provide the user with 



a more informed view of the operation of the system instead 
of requiring a guess as to what is going wrong. 

HP's earlier desktop computers have always provided 
access to the hardware registers on the I/O cards to provide 
customers with access to features not provided by the I/O 
language of their system. However, the new-generation HP- 
GIO cards are far more complex to program and in addition, 
do not have conventional registers, Thus^ the SUN drivers 
provide a synthesized set of registers, called pseu do regis- 
ters. This provides the user with the same model as on the 
HP 9845 Computer for accessing features of an I/O card not 
normally provided by the system, but done in cooperation 
with the driver. Thus, the driver has the opportunity to 
provide additional functions in an isolated manner. This 
allows the same pseudoregisters to be used for different 
implementations of the same type of interface card, which 
increases the portability of user applications. 

The SUN drivers support the broad set of peripherals 
produced by Hewlett-Packard. Instead of initially supply- 
ing a core set and then adding less-essential drivers at a 
later time, SUN provides support for all peripherals that 
make reasonable sense for the HP 9000 marketplace* One 
additional driver that is somewhat unusual is the mem- 
ory driver. This driver uses the main memory of the running 
system to simulate a disc drive. The code required to pro- 
vide this driver is a great deal simpler than if this function 
were provided at a higher level. The result is that a user 
can develop an application that accesses a disc file and 
then decide to store the data in main memory to gain the 
performance advantage of not having to spend the time to 
access a disc drive. The change is trivial using the memory 
driver; simply revise the reference to the specific mass 
storage device to be the memory driver rather than the 
originai disc drive. 
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alsc interested in skiing, hiking, spoils cars, and 
audio systems 



Robert M. Ldnk 

f Bob Lenks contributions 

have resulted in two pafii^rs 

related to a system for soft- 
ware performance in- 
strumentation. Joinirtg HP 
m 1981, he worked on the 
l,'0 primitives and local 
area network services for 
I the Series 5(H}. fstow he is 

1 1 'I f . working on the HP-UX ker- 
nel for the Se ries 200 Camp u ter s . A m ember of the 
ACM, he holds a BA degree in mathematics (1 975J 
and an MS degree in computer science ( 1 981 ) f rom 
the University of Connecticut. Born m New York, 
New York, he now hves m Fort ColNns Colorado. 
He IS married and likes square da ncmg and cross- 
country skiing, 
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Donald L. Hammond 

Don Hammond was re- 
cently named director of 
Hewlett-Packard 
La&oratones, Bristol. Eng- 
land He joined HP in 195Q 
as manager of the quartz 
crystal department, and in 
1963, he became manager 
of physical research and 
development From 1 066 to 
1979. he was dtrector of the Physicaf Electronics 
Laboratory of Hewlett-Packard Laboratories, and 
from 1979 until his move to England, he was direc- 
tor of the Physical Research Center of HP 
Laboratories, with responsibility for R&D in medical 
and analytical instruments, computer peripherals, 
factory automation, and lithography He is a 
member of the American Physical Society, a fellow 
of the IEEE, and a member of the National Academy 
of Sciences evaluation committee lor the U.S. Hb- 
tional Bureau of Standards and the U.S. Naval 
Observatory He holds BS, MS and DSc degrees 
in physics trom Colorado State University. A native 
of Kansas City. Missoun, Don is marned and has 
five Children He served for ten years on the board 
of trustees of the Pato Alto, CaNfornia Unified 
School District, and has been a member of vahouS 
presidential, gubernatorial, and industry com- 
mittees on education and technology 
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Viewpoints 

Coping with Prior Invention 



by Donald L. Hammond 



THIS MONTH, HEWLETT-PACKARD is introducing a new 
printer, the Thinkjet (HP 2225), which offers what we be- 
llevft is an unprecedented combination of features: 150 
character-per-second printing speed, archival print on ordinary 
paper, small size, quiet operation, and low cost — both initial cost 
and total cost of ownership. Power requirements are so low that 
one model is available with a battery pack that provides more 
than three hours of printing, or about 200 pages. These advantages 
have been made possible by a new ink jet printing technology, 
which we have called thermal Ink jet, or more picturesquely, 
"Thinkjet," to differentiate it clearly from the more common kind 
of thermal print ing, which requires special paper. 

We think the story of Ibis technology development is an interest- 
ing example of what can happen in today's fast-moving technolog- 
ical environment. In our HP Laboratories at Palo Alto^ in the fall 
of 1978, John Vaught was looking for a new printing method that 
would have the advantage of inherent simplicity compared with 
the rather complex electrophotographic process used in the HP 
2680A Laser Printer, for which John had designed the optical 
scanning package. 

He started with the idea of turning ink into vapor by high-speed 
electrolysis and heating, using pressure to eject drops. When this 
was found to work but with serious failure rates, he conceived 
the idea of using a small resistor, which when heated for a few 
microseconds by a current pulse, created bubbles, thereby ejecting 
drops of ink from a nozzle. This was first demonstrated in March 
1979. 

We proceeded to develop this idea, amidst some skepticism that 
the necessary performance and reliability could ever be achieved. 
The Think)et printer is testimony that these concerns were dis- 
persed by extensive development work in several HP organizations 
on the process and structure. One of the key concepts, originated 
at HP's Corvallis Division, was a totally disposable ink jet head 



with a self-contained ink supply. 

It is not uncommon, when an important problem such as quality 
printing receives the attention of many people, that independent 
conception occurs in isolated research centers. Such was the case 
with Thinkjet. In September 1 981 we learned of the existence of 
the same concept under development at Canon, Inc., in japan, 
Ichiro Endo had conceived the idea independently, with an earlier 
invention date. Canon referred to the technology'' as "Bubblejel," 

Since we in HP were convinced that this new technology had 
great promise, the arrival of a new player in this arena caused 
some concern as to our respective technical positions. There were 
a number of options but the most attractive for HP was to work 
with Canon, Excellent ties between the two companies had already 
been established as a result of our acquisition from them of tech- 
nology for electrophotographic printers several years earlier. 

Hewlett-Packard and Canon have agreed to cooperate in the 
technology development. Because this process started in 1983, the 
sharing of technical data has had no major impact on our first 
product release, but we can feel the positive effect that it is having 
on our continuing developments. Canon has reflected to us similar 
feelings. Working with a group that represents a combination of 
cooperation and competition has provided a valuable perspective, 
especially increased objectivity, for the technical and management 
teams of both companies. 

This experience has reinforced the principle that technology 
alone can rarely make a significant contribution in this complex^ 
fast-moving world. There are equally valuable elements, some- 
times involving the resolution of relationships in the spirit of 
international competilion and cooperation^ that can have dramatic 
effects on our ability to tiring that technology to the market. 

We will be reporting in a future issue on more details of these 
developments, including the Thinkjet printer. 
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